Commissioning Guide: ATN 910&910I&910B&950B Multi-Service Access Equipment V200R003C10

ATN 910&910I&910B&950B Multi-Service Access
Equipment
V200R003C10
Commissioning Guide
Issue 02
Date 2014-04-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. 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 02 (2014-04-30) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Equipment
Commissioning Guide About This Document
About This Document
Purpose
This document describes the commissioning process of the ATN.
This document describes the commissioning flow and method.
NOTE
The usage precautions are as follows:

l A device can store keys in plaintext, reversible algorithm encryption, or irreversible algorithm
encryption mode. The plaintext mode has the low security level, and the irreversible algorithm
encryption mode has the highest security level. Use different storage modes for different scenarios.
Exercise caution when using an insecure storage mode. The system automatically selects the
irreversible algorithm encryption mode to store local user keys. Generally, the reversible algorithm
encryption mode is used to store protocol keys to meet interworking requirements.
l If the plaintext mode is used, a password is stored in plaintext in the configuration file. This results
in high security risks. The plaintext mode applies only to scenarios with special requirements, such
as compatibility and interworking requirements.
l Using a password or a key without a change leaves the password prone to being stolen or cracked,
which is more likely in a longer duration. Changing the password on a regular basis may avoid such
incidences, and therefore is recommended.
Related Version
The following table lists the product version related to this document.
Product Name Version
l ATN 910 V200R003C10

l ATN 910I
l ATN 910B
l ATN 950B
Intended Audience
This document is intended for:
Issue 02 (2014-04-30) Huawei Proprietary and Confidential ii

Equipment
l Commissioning Engineer
Symbol Conventions
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
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.
Issue 02 (2014-04-30) Huawei Proprietary and Confidential iii

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

vertical bars. Several items or no item can be selected.
GUI Conventions
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"

signs. For example, choose File > Create > Folder.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 02 (2014-04-30)

This document has the following updates:
Known bugs are fixed.
Changes in Issue 01 (2014-01-31)

This document is the first release of the V200R003C10 version.
Issue 02 (2014-04-30) Huawei Proprietary and Confidential iv

Equipment
Commissioning Guide Contents
Contents
About This Document.....................................................................................................................ii

1 Commissioning Flow....................................................................................................................1
2 Logging In to the ATN..................................................................................................................3
2.1 Logging In to the ATN by Using SSH...........................................................................................................................5
2.2 Logging In to the ATN by Using Telnet......................................................................................................................13
2.3 Logging In to the ATN by Using the Console Interface..............................................................................................17
2.4 Clearing the Password..................................................................................................................................................20
3 Checking the Hardware..............................................................................................................22

3.1 Checking the Software Version....................................................................................................................................23
3.2 Checking the Health Status of the ATN.......................................................................................................................24
3.3 Checking the Board Registration Status.......................................................................................................................24
3.4 Checking the Fan Status...............................................................................................................................................26
3.5 Checking the Power Status...........................................................................................................................................27
3.6 Checking System Time.................................................................................................................................................28
3.7 Checking the Interface Status.......................................................................................................................................28
3.8 Checking Alarm Information........................................................................................................................................30
4 Commissioning the Link Layer................................................................................................31

4.1 Checking Ethernet Interfaces........................................................................................................................................32
4.2 Checking E-Carrier Interfaces......................................................................................................................................34
4.3 Checking the Optical Power of Interfaces....................................................................................................................36
4.4 Commissioning T1 Carrier Interfaces..........................................................................................................................38
4.5 Commissioning XDSL Interfaces.................................................................................................................................41
4.6 Commissioning ATM Interfaces..................................................................................................................................43
4.7 Commissioning TDM Interfaces..................................................................................................................................49
4.8 Commissioning MP Interfaces.....................................................................................................................................56
5 Commissioning Services and Protocols..................................................................................61

5.1 Commissioning Static Routes.......................................................................................................................................63
5.2 Commissioning OSPF Routes......................................................................................................................................65
5.3 Commissioning IS-IS Routes.......................................................................................................................................71
5.4 Commissioning IBGP Routes.......................................................................................................................................75
Issue 02 (2014-04-30) Huawei Proprietary and Confidential v

Equipment
Commissioning Guide Contents
5.5 Commissioning MPLS LDP.........................................................................................................................................81

5.6 Commissioning MPLS TE............................................................................................................................................86
5.7 Commissioning BGP/MPLS IP VPN...........................................................................................................................90
5.8 Commissioning VPWS.................................................................................................................................................97
5.9 Commissioning VPLS................................................................................................................................................102
5.10 Commissioning BFD................................................................................................................................................107
5.11 Commissioning a DCN.............................................................................................................................................110
5.12 Commissioning Clocks.............................................................................................................................................113
6 Connecting a Device to the NMS...........................................................................................116
Issue 02 (2014-04-30) Huawei Proprietary and Confidential vi

Equipment
Commissioning Guide 1 Commissioning Flow
1 Commissioning Flow
This chapter describes the ATN commissioning flow. Users can know the entire process of
ATN commissioning in site deployment after reading this section.
Figure 1-1 shows the commissioning flow.
Figure 1-1 Commissioning flow
Logging In to the
Equipment
Checking the
Hardware
Commissioning the
Link Layer
Commissioning
Services and
Protocols
Table 1-1 describes commissioning procedures.
Table 1-1 Commissioning procedures
Commissioning Procedure Description
Logging In to the ATN Describes how to log in to the ATN for later
commissioning. Three login methods, login
by using the console interface, Telnet, and
Secure Shell (SSH), are introduced.
Issue 02 (2014-04-30) Huawei Proprietary and Confidential 1

Equipment
Commissioning Guide 1 Commissioning Flow
Commissioning Procedure Description
Checking the Hardware Describes how to check the power supply,

fans, boards, and interfaces to prepare for
ATN commissioning.
Commissioning the Link Layer Describes how to commission the link layer
when the ATN is connected to othertransport
devices.
Commissioning Services and Protocols Describes how to commission services and

protocols, especially routing protocols,
tunnel services, VPN services, and BFD
functions, when the ATN is connected to
other transport devices.

Equipment
Commissioning Guide 2 Logging In to the ATN
2 Logging In to the ATN
About This Chapter
This chapter describes how to log in to the ATN for later commissioning. Three login methods,
login by using the console interface, Telnet, and SSH, are introduced.
NOTE
Command levels are associated with user privilege levels. A user can run only the commands at the same
or lower level than the user privilege level. This mechanism ensures device security.
For more information about user privilege level configurations, see ATN Multi-service Access
Equipment Configuration Guide - Basic Configurations - Configuring User Login..
l When you log in using the SSH (STelnet) method for the first time, the default user name is root, and
the default password is Changeme_123. To improve service security, change the user name and
password immediately after configuring services.
l When you log in through a console interface for the first time, no default user name or password is
available. Therefore, configure a user name and password after the login.
l The console interface login method is still available if you log in not through a console interface.
Therefore, to prevent unauthorized users from logging in through the console interface, configure a
user name and password for the console interface login method immediately after you log in using
another method and configure services. This configuration prevents unauthorized users from querying
or modifying service configurations.
l After the ATN device is powered on, it will automatically bind the management network interface to
the VPN for exclusive use (__LOCAL_OAM_VPN__) and configure the IP address 129.0.0.1/24 for
the management network interface.
Use the IP address 129.0.0.1 to stelnet to the ATN that is powered on for the first time.
The user can configure any other IP address for the network segment 129.0.0.0/24 on the PC, and
directly log in to the ATN device using the user name and password for on-site equipment maintenance.
The IP address of the management network interface can be changed or deleted. The management
interface can be disabled as required.
2.1 Logging In to the ATN by Using SSH

This section describes how to log in to the ATN by using SSH. SSH is a secure remote login
protocol developed based on the traditional Telnet protocol. Compared with Telnet, SSH is
greatly improved in terms of the authentication mode and data transmission security.
2.2 Logging In to the ATN by Using Telnet

Equipment
This section describes how to log in to the ATN by using Telnet. A Telnet operation allows you
to log in to a remote device for device management.
2.3 Logging In to the ATN by Using the Console Interface

This section describes how to use the HyperTerminal in Windows on the PC to log in to the
ATN after setting up a local configuration environment with the console interface.
2.4 Clearing the Password

This section describes how to clear the password by setting DIP switches when a user cannot
log in a device due to an invalid login password.

Equipment
2.1 Logging In to the ATN by Using SSH

This section describes how to log in to the ATN by using SSH. SSH is a secure remote login
protocol developed based on the traditional Telnet protocol. Compared with Telnet, SSH is
greatly improved in terms of the authentication mode and data transmission security.
Figure 2-1 shows the networking diagram for logging in to the ATN by using SSH.
Figure 2-1 Networking diagram for logging in to the ATN by using SSH
network
SSH Client SSH Server
Prerequisite
l The ATN is running properly.The status indicators are green.
l The ATN has been logged in using the console interface and an IP address for each interface
has been configured on the ATN.
l A direct or reachable route exists between the SSH client and the ATN.
Perform the following configurations on the ATN that serves as the SSH server:
Procedure
Step 1 Configure a VTY user interface to support SSH.
1. Run the system-view command to enter the system view.
2. Run the user-interface [ ui-type ] first-ui-number [ last-ui-number ] command to enter the
user interface view.
3. Run the authentication-mode aaa command to specify AAA authentication as the
authentication mode.
4. Run the protocol inbound ssh command to configure SSH as the access protocol in the
VTY user interface view.
NOTE
AAA authentication must be configured in the VTY user interface view; otherwise, the protocol
inbound ssh command does not take effect.
Step 2 Run the ssh user user-name command in the system view to create an SSH user.
Step 3 Create an RSA or DSA key pair.

l Run the rsa local-key-pair create command to create a local RSA key pair.

Equipment
NOTE
l Configure the rsa local-key-pair create command to generate a local key pair before completing
other SSH configurations. The minimum length of the server key pair and the host key pair is 512
bits, and the maximum length is 2048 bits.
l After a local key pair is generated, you can run the display rsa local-key-pair public command
to view the public key in the local key pair.
l To clear the local RSA key pair, run the rsa local-key-pair destroy command to destroy all local
RSA key-pairs, including the local key-pair and server key-pair.
Check whether all local RSA key pairs are destroyed after running the rsa local-key-pair
destroy command. The rsa local-key-pair destroy command configuration takes effect only once
and therefore will not be saved in the configuration file.
l Run the dsa local-key-pair create command to generate the RSA local-key-pair.
NOTE
l You must configure the dsa local-key-pair create command to generate a local key pair before
completing other SSH configurations. The length of the server key pair and the host key pair can
be 512 bits, 1024 bits and 2048 bits. By default, the length of the key pair is bits.
l After a local key pair is generated, you can run the display dsa local-key-pair public command
to view the public key in the local key pair.
l To clear the local DSA key pair, run the dsa local-key-pair destroy command to destroy all local
DSA key-pairs, including the local key-pair and server key-pair.
Check whether all local DSA key pairs are destroyed after running the dsa local-key-pair
destroy command. The dsa local-key-pair destroy command configuration takes effect only once
and therefore will not be saved in the configuration file.
Step 4 Perform the operations as described in Table 2-1 based on the configured SSH user
authentication mode.
Table 2-1 Configuring an authentication mode for the SSH user
Operation Command Description
Configure 1. Run the ssh user user-name If local or HuaWei Terminal

Password authentication-type password Access Controller Access Control
Authentication command System (HWTACACS)
authentication is used and there
are only a few users, use password
authentication.
2. Run the aaa command to enter -

the AAA view.
3. Run the local-user user-name The user name must be the same
password cipher password to the SSH user.
command to configure the user By default, the administrators are
name and the password for the local all in the domain default_admin.
user.
4. Run the local-user user-name -

service-type ssh command to set
the access type of the local user to
SSH.

Equipment
Configure RSA 1. Run the ssh user user-name -

authentication authentication-type rsa command
to configure RSA authentication.
2. Run the rsa peer-public-key key- Huawei data communications

name [ encoding-type { der | devices support only the DER
openssh | pem } ] command to format for RSA keys before VRP
configure an encoding format for an V500R012C01 version. If you use
RSA public key and enter the RSA an RSA key in non-DER format,
public key view. use a third-party tool to convert
The default encoding format is the key into a key in DER format.
distinguished encoding rules (DER) In addition to DER, RSA keys
for an RSA public key. need to support the privacy-
enhanced mail (PEM) and
OpenSSH formats since VRP
V500R012C01 to improve RSA
usability.
Third-party software, such as
SecureCRT, PuTTY, OpenSSH,
and OpenSSL, can be used to
generate RSA keys in different
formats. The details are as
follows:
l The SecureCRT and PuTTY
generate RSA keys in PEM
format.
l The OpenSSH generates RSA
keys in OpenSSH format.
l The OpenSSL generates RSA
keys in DER format.
3. Run the public-key-code begin -

command to enter the public key
edit view.
4. Enter hex-data to edit the public l In the public key edit view,
key. only hexadecimal strings
complying with the public key
format can be typed in. Each
string is randomly generated
on an SSH client. For detailed
operations, see manuals for
SSH client software.
l After entering the public key
edit view, paste the RSA
public key generated on the
client to the server.

Equipment
5. Run the public-key-code end -

command to exit from the public
key edit view.
6. Run the peer-public-key end l Running the peer-public-key

command to return to the system end command generates a key
view. only after a valid hex-data
format is entered.
l If the peer-public-key end
command is used after the key
key-name specified in Step 2 is
deleted in another window, the
system prompts a message,
indicating that the key does
not exist, and the system view
is displayed.
7. Run the ssh user user-name -

assign rsa-key key-name command
to assign the SSH user a public key.
Configure DSA 1. Run the ssh user user-name -

authentication authentication-type dsa command
to configure DSA authentication.
2. Run the dsa peer-public-key Huawei data communications

key-name encoding-type { der | devices support the DER and
openssh | pem } command to PEM formats for DSA keys
configure an encoding format for a before VRP V500R012C01
DSA public key and enter the DSA version. If you use an RSA key in
public key view. non-DER/PEM format, use a
third-party tool to convert the key
into a key in DER or PEM format.
In addition to DER, DSA keys
need to support the PEM and
OpenSSH formats since VRP
V500R012C01 to improve DSA
usability.
3. Run the public-key-code begin -

command to enter the public key
edit view.

Equipment
4. Enter hex-data to edit the public l In the public key edit view,
key. only hexadecimal strings
format can be typed in. Each
string is randomly generated
on an SSH client. For detailed
operations, see manuals for
SSH client software.
l After entering the public key
edit view, paste the RSA
public key generated on the
client to the server.
5. Run the public-key-code end -

command to exit from the public
key edit view.
6. Run the peer-public-key end l Running the peer-public-key

command to return to the system end command generates a key
view. only after a valid hex-data
format is entered.
l If the peer-public-key end
command is used after the key
key-name specified in Step 2 is
deleted in another window, the
system prompts a message,
indicating that the key does
not exist, and the system view
is displayed.
7. Run the ssh user user-name -

assign dsa-key key-name command
to assign the SSH user a public key.
Step 5 Run the ssh user username service-type { sftp | stelnet | all } command in the system view to
configure a service type for the SSH user.
Step 6 Run the stelnet server enable command in the system view to enable STelnet.
----End
Commissioning Results
Log in to the ATN by using SSH. This section describes only the SSH login by using the PuTTY
program.
1. As shown in Figure 2-2, set the IP address of the ATN to 129.0.0.1 and the login protocol
to SSH.

Equipment
Figure 2-2 Login using the PuTTY program
NOTE
After the ATN is powered on for the first time, you can log in to it in STelnet mode. The IP address
of the management network interface Ethernet0/0/0 (the console interface) is 129.0.0.1. If the
ATN has accessed the network when it is powered on for the first time, its IP address 129.0.0.1 will
be automatically changed to the IP address that DHCP obtains during the startup.
2. Enter the user name root and the password Changeme_123.

Equipment
Figure 2-3 Login using the PuTTY program
NOTE
After the ATN is powered on for the first time, you can log in to it in STelnet mode. The user name
and password are root and Changeme_123 respectively. After logging in to the ATN, change the
default password in time.
Troubleshooting
If the SSH login fails, perform the following operations:
1. Check that network connections are proper.

Check whether unstable connections that cause packet loss or occasional login failures exist
in the network. If network connections are improper, follow the procedure described in
"The Ping Operation Fails" in the ATN Multi-service Access Equipment Troubleshooting
to locate and rectify the fault and ensure a stable connection between the SSH client and
the SSH server.
2. Check that SSH services are enabled.
Run the display ssh server status command to view configurations on the SSH server.
<HUAWEI> display ssh server status
SSH version :1.99
SSH connection timeout :60 seconds
SSH server key generating interval :0 hours
SSH Authentication retries :3 times
SFTP server :Disable
Stelnet server :Disable
The command output shows that the SFTP and STelnet servers are not enabled. A user can
log in to the ATN by using SSH only after SSH services are enabled on the ATN. Run the
following command to enable the SSH server.
<HUAWEI> system-view
[HUAWEI] stelnet server enable
3. Check that the access protocol has been correctly configured in the VTY user interface
view.
[HUAWEI] user-interface vty 0 4

Equipment
[HUAWEI-ui-vty0-4] display this

user-interface vty 0 4
authentication-mode aaa
user privilege level 3
idle-timeout 0 0
protocol inbound ssh
The protocol inbound { all | ssh | telnet } command is used to specify protocols supported
by the current user interface. telnet is the default parameter. If telnet is specified, SSH
login is prohibited. If ssh or all is specified, SSH login is allowed.
4. Check that the RSA public key is configured.
The ATN that serves as an SSH server must be configured with a local key pair.
Run the display rsa local-key-pair public command to check whether a key pair has been
configured on the SSH server. If no key pair has been configured, run the rsa local-key-
pair create command to create one.
[HUAWEI] rsa local-key-pair create
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus[default = 512]: 768
Generating keys...
...........................++++++++
.++++++++
...............+++++++++
......+++++++++
5. Check that the user service type, authentication type, and authentication service type (for
password authentication only) have been configured.
l Create an SSH user.
[HUAWEI] ssh user hello@163.net
[HUAWEI] ssh user hello@163.net authentication-type all
[HUAWEI] ssh user hello@163.net service-type all
[HUAWEI] ssh user hello@163.net sftp-directory cfcard:/ssh
Configure the same SSH user in the AAA view and set the authentication service type.
[HUAWEI] aaa
[HUAWEI-aaa] local-user hello@163 password cipher abc-pass
[HUAWEI-aaa] local-user hello@163.net service-type ssh
l Configure default password authentication for the SSH user.

[HUAWEI] ssh authentication-type default password
Configure the same SSH user in the AAA view and set the authentication service type.
[HUAWEI] aaa
[HUAWEI-aaa] local-user hello@163 password cipher abc-pass
[HUAWEI-aaa] local-user hello@163.net service-type ssh
6. Check whether login users on the ATN have reached the maximum.
Like Telnet users, SSH users use VTY user interfaces when logging in to the ATN. The
number of available VTY user interfaces ranges from 5 to 15. If the number of login users
is greater than 15, a new connection request will be denied by the ATN.
Log in to the ATN by using the console interface. Then, run the display users command
to check whether the VTY user interfaces are all used. By default, a maximum of five VTY
user interfaces are available to login users.
<HUAWEI> display user-interface maximum-vty
Maximum of VTY user:5
<HUAWEI> display users
User-Intf Delay Type Network Address AuthenStatus AuthorcmdFlag
34 VTY 0 03:31:35 TEL 10.138.81.138 pass no
Username : Unspecified

Equipment
35 VTY 1 03:51:58 TEL 10.137.128.126 pass no

36 VTY 2 00:10:14 TEL 10.138.81.184 pass no
37 VTY 3 02:31:58 TEL 10.138.80.199 pass no
+ 39 VTY 4 00:00:00 TEL 10.138.78.80 pass no
If login users on the ATN have reached the maximum, the user-interface maximum-vty
vty-number command can be run to increase the allowed maximum number of login users
that can use VTY user interfaces to 15.
[HUAWEI] user-interface maximum-vty 15
7. Check that an ACL is configured in the VTY user interface view.

If an ACL is configured but the IP address of a client from which the access is permitted
is not specified in ACL rules, the client cannot log in to the ATN by using SSH. This means
that to allow a client log in to the ATN by using SSH, you must specify the IP address of
the client in the permit rule of the ACL bound to the user interface.
8. Check the SSH version.
Run the display ssh server status command to check the SSH version.
<HUAWEI> display ssh server status
SSH version :1.99
SSH connection timeout :60 seconds
SSH server key generating interval :0 hours
SSH Authentication retries :3 times
SFTP server :Disable
Stelnet server :Disable
l If the client logs in to the server by using SSHv1, the version compatible capability
needs to be enabled on the server.
[HUAWEI] ssh server compatible-ssh1x enable
l If the client logs in to the server by using SSHv2, the version compatible capability does
not need to be enabled on the server.
[HUAWEI] undo ssh server compatible-ssh1x enable
9. Enable first-time authentication on the SSH client.

[HUAWEI] ssh client first-time enable
10. If the SSH login still fails, collect the following information and contact Huawei technical
support personnel:
l Results of the preceding operation procedure
l Configuration files, log files, and alarm files of the ATN
2.2 Logging In to the ATN by Using Telnet

This section describes how to log in to the ATN by using Telnet. A Telnet operation allows you
to log in to a remote device for device management.
Figure 2-4 shows the networking diagram for logging in to the ATN by using Telnet.

Equipment
Figure 2-4 Networking diagram for logging in to the ATN by using Telnet
network
Telnet Client Telnet Server
Prerequisite
l The ATN is running properly.
l The ATN has been logged in using the console interface and an IP address for each interface
has been configured on the ATN.
l A direct or reachable route exists between the Telnet client and the ATN.
Perform the following configurations on the ATN that serves as the Telnet server:
Procedure
Step 1 Enable the Telnet function.
2. Run the telnet server enable command to enable the function of a Telnet server.
Step 2 Set the maximum number of users that are allowed to log in to the ATN at the same time.
2. Run the user-interface maximum-vty number command to set the maximum number of
login users that can use VTY user interfaces on the ATN.
Step 3 Configure a user authentication mode.
One of them can be selected as needed.
NOTE
l On the ATN, the default authentication mode is password authentication.

l If users with passwords need to be created and managed on the ATN, AAA authentication is
recommended.
l Configure password authentication.
3. Run the set authentication password [ cipher password ] command to set the password
used in authentication.
l Configure AAA authentication.

Equipment
3. Run the authentication-mode aaa command to configure AAA authentication.

4. Run the aaa command to enter the AAA view.
5. Run the local-user user-name password command to configure the local user name and
password.
6. Run the quit command to exit from the AAA view.
Step 4 Run the user privilege level level command in the user interface view to control the user rights.
----End
After the preceding configurations are complete, perform the following operations to check
whether the configurations are correct.
1. Run the Telnet client program on the PC, and enter the IP address of the interface to which
you want to connect to.
2. Enter the user name and password in the login window. If the user is authenticated, a
command line prompt such as <HUAWEI> is displayed. It indicates that you have entered
the user view.
Troubleshooting
If the Telnet login fails, perform the following operations:
1. Check that network connections are proper.
Run the ping command on the client to check network connections. If ping results are
negative, network connections are faulty and Telnet connections cannot be set up.
Check whether unstable connections that cause packet loss or occasional login failures exist
in the network. If network connections are faulty, follow the procedure described in "The
Ping Operation Fails" in the ATN Multi-service Access Equipment Troubleshooting to
locate and rectify the fault and ensure that the Telnet client can successfully ping the Telnet
server.
2. Check whether login users on the ATN have reached the maximum.
Log in to the ATN by using the console interface. Then, run the display users command
to check whether the VTY user interfaces are all used. By default, a maximum of five VTY
user interfaces are available to login users. You can run the display user-interface
maximum-vty command to view the allowed maximum number of login users.
<HUAWEI> display user-interface maximum-vty
Maximum of VTY user:5
<HUAWEI> display users
User-Intf Delay Type Network Address AuthenStatus AuthorcmdFlag
34 VTY 0 03:31:35 TEL 10.138.81.138 pass no
35 VTY 1 03:51:58 TEL 10.137.128.126 pass no
36 VTY 2 00:10:14 TEL 10.138.81.184 pass no
37 VTY 3 02:31:58 TEL 10.138.80.199 pass no
+ 38 VTY 4 00:00:00 TEL 10.138.78.80 pass no
If login users on the ATN have reached the maximum, the user-interface maximum-vty
vty-number command can be run to increase the allowed maximum number of login users

Equipment
that can use VTY user interfaces to 15, and you should configure authentication modes for
newly added VTY user interfaces.
[HUAWEI] user-interface maximum-vty 15
[HUAWEI-ui-vty5-14] authentication-mode aaa
3. Check that an ACL is configured in the VTY user interface view.

acl 2000 inbound
idle-timeout 0 0
If an ACL is configured but the IP address of a client from which the access is permitted
is not specified in ACL rules, the client cannot telnet to the ATN. This means that to allow
a client to telnet to the ATN, you must specify the IP address of the client in the permit rule
of the ACL bound to VTY user interfaces.
4. Check that the access protocol has been correctly configured in the VTY user interface
view.
idle-timeout 0 0
protocol inbound ssh
The protocol inbound { all | ssh | telnet } command is used to specify protocols supported
by the current user interface. telnet is the default parameter. If ssh is specified, Telnet login
is prohibited. If all is specified, both Telnet login and SSH login are allowed.
5. Check whether extended VTY user interfaces 16 to 20 are available to login users.
These user interfaces are reserved for NMS users. Whether VTY user interfaces 0 to 14 are
all used, VTY user interfaces 16 to 20 are open to NMS users (whose user type is net-
manager) only, not common login users.
The display users command can be used to check the user login information of every VTY
user interface.
6. Check that a password has been set in the user interface view.
If the authentication-mode password command has been run in the VTY user interface
view to set the authentication mode to password, the set authentication password
command must be run to set an authentication password.
The authentication mode can also be set to aaa by running the authentication-mode aaa
command.
7. Check that the user level is correct.
If the authentication mode in the VTY user interface view is set to password or none, you
need to check the user level. Low-level users, after login, are not allowed to run high-level
commands such as the system-view command.
If you use an administrator account to log in to the ATN, you can run the user privilege
level level command to configure the level of commands that the user logging in through
the current user interface can use.

Equipment
NOTE
By default, command levels are 0, 1, 2, and 3. Before the upgrade of command levels, user levels 3
to 15 are the same, which are all management levels.
8. If the Telnet login still fails, Collect the following information and contact Huawei technical
support personnel:
2.3 Logging In to the ATN by Using the Console Interface

This section describes how to use the HyperTerminal in Windows on the PC to log in to the
ATN after setting up a local configuration environment with the console interface.
Context
Figure 2-5 shows the networking diagram for logging in to the NE80E/40E by using the console
interface
Figure 2-5 Networking diagram for logging in to the ATN by using the console interface
PC ATN
Prerequisite
l The PC is connected to the ATN through an asynchronous interface.
l Installing terminal emulation program on the PC (such as Windows XP HyperTerminal)
NOTE
The console port applies the non-standard serial port communication cable sequence. For more information, see
Management Cables in Hardware Description.
Perform the following configurations on the HyperTerminal on the PC.
Procedure
Step 1 Use a serial cable to connect the serial interface on the PC and the console interface on the
ATN.
Step 2 Start the HyperTerminal on the PC.
Choose Start > Programs > Accessories > Communications to start the HyperTerminal in
Windows.
Step 3 Set up a connection.

Equipment
As shown in Figure 2-6, enter the name of the new connection in the Name text box, and select
an icon. Then, click OK.
Figure 2-6 Setting up a connection
Step 4 Set a connection port.
In the Connect To dialog box shown in Figure 2-7, select a port from the drop-down list box
of Connect using according to the port actually used on the PC or terminal. Then, click OK.
Figure 2-7 Setting a connection port

Equipment
Step 5 Set communication parameters.
When the COM1 Properties dialog box is displayed as shown in Figure 2-8, set the COM1
properties according to the description in Figure 2-8 or by clicking Restore Defaults.
NOTE
l Setting the COM1 properties according to the description in Figure 2-8 and setting them by clicking
Restore Defaults have the same effect. The default settings of the console interface will be used.
l When you log in to the ATN by using the console interface, ensure that the COM1 properties on the
HyperTerminal are consistent with the interface attribute settings on the ATN. Otherwise, the login
will fail. This means that if default settings are not used for the interface attributes on the ATN, the
COM1 properties on the HyperTerminal must be changed to be consistent with the interface attribute
settings on the ATN.
Figure 2-8 Setting communication parameters
----End
Commissioning Result
After the preceding configurations are complete, press Enter. An initial password is required
for the first login. Set an authentication password. The system automatically saves the set
password.
An initial password is required for the first login via the console.
Set a password and keep it safe! Otherwise you will not be able to login via the
console.
Please configure the login password (6-16)

Equipment
Enter Password:
Confirm Password:
If the login fails, click Disconnect and then Call. If the login still fails, repeat Step 1 to check
whether the parameters or physical connections are correct. If they are correct, log in to the
ATN again.
2.4 Clearing the Password

This section describes how to clear the password by setting DIP switches when a user cannot
log in a device due to an invalid login password.
Prerequisites
The device has been normally powered on.
Context
This operation is performed when an attempt to log in to a device fails because the user forgets
the password.
ATN 910/ATN 950B support this operation.
Procedure
Step 1 Remove the system control board.
NOTE
For a device equipped with active and standby control boards, remove both boards and then perform related
operations on them.
Step 2 Set DIP switches 1 to 4 on the system control board to 1, 1, 0, and 1 respectively.
The number 1 indicates that the DIP switch is set to the side with numbers while the number 0
indicates that the DIP switch is set to the side with letters.
Step 3 Install the removed system control board back.

When the device starts, it identifies the status of DIP switches and clears the configuration files
loaded onto it. In this way, the password is also cleared.
Step 4 Five minutes later, the configuration files are cleared, then remove the system control
board.
Step 5 Set DIP switches 1 to 4 to 0 each.

NOTE
This operation prevents the configurations files from being cleared each time the device restarts.
Step 6 Install the removed system control board back.
Default settings of the device are restored.
----End

Equipment
Follow-up Procedure
Log in to the device.

Equipment
Commissioning Guide 3 Checking the Hardware
3 Checking the Hardware
About This Chapter
This chapter describes how to check the power supply, fans, boards, and interfaces prior to
commissioning the ATN.
3.1 Checking the Software Version

This section describes how to determine if the software version meets the deployment
requirements.
3.2 Checking the Health Status of the ATN

This section describes how to verify whether the current status of the ATN meets the deployment
requirements.
3.3 Checking the Board Registration Status

This section describes how to determine whether the boards are properly installed and function
normally.
3.4 Checking the Fan Status

This section describes how to check whether fans function properly. By default, fans work in
auto adjusting mode. When the ambient temperature rises sharply, you can manually set it to
full speed mode to protect the device.
3.5 Checking the Power Status

This section describes how to verify whether power modules function properly.
3.6 Checking System Time

This section describes how to verify whether the system time meets the system requirements.
3.7 Checking the Interface Status

This section describes how to verify the interface status.
3.8 Checking Alarm Information

This section describes how to verify alarms and faults about the ATN.

Equipment
3.1 Checking the Software Version

This section describes how to determine if the software version meets the deployment
requirements.
Prerequisites
The ATN has been logged in to. For more information, see 2 Logging In to the ATN.
Procedure
Step 1 Run the display version [ slot slot-id ] command to view the version information.
<HUAWEI> display version
Huawei Versatile Routing Platform Software
VRP (R) software, Version 5.150 (ATN910 V200R003C10)
Copyright (C) 2000-2010 Huawei Technologies Co., Ltd.
ATN910 uptime is 0 day, 10 hours, 15 minute
ATN910 version information:
---- More ----
If the version displayed in boldface in the preceding information on the ATN is consistent with
the version required for deployment, go on with the subsequent commissioning.
Step 2 Run the display startup command to view the system software and configuration files for the
current and next startup.
<HUAWEI> display startup
MainBoard:
Configured startup system software: cfcard:/V200R003C10.cc
Startup system software: cfcard:/V200R003C10.cc
Next startup system software: cfcard:/V200R003C10.cc
Startup saved-configuration file: cfcard:/vrpcfg.zip
Next startup saved-configuration file: cfcard:/vrpcfg.zip
Startup paf file: cfcard:/paf-V200R003C10.txt
Next startup paf file: cfcard:/paf-V200R003C10.txt
Startup license file: cfcard:/license-V200R003C10.txt
Next startup license file: cfcard:/license-V200R003C10.txt
Startup patch package: cfcard:/patch.bat
Next startup patch package: cfcard:/patch.bat
If the names of system software and configuration files, displayed in boldface in the preceding
information, for the next startup are consistent with that required for deployment, go on with the
subsequent commissioning.
----End
Troubleshooting
If the software version does not meet the deployment requirement, it needs to be upgraded.
NOTE
Before upgrading the software version, contact Huawei technical support personnel to get the reference
documents, including the Version Upgrade Guide, Release Notes, Patch Operation Guide, and
Paf&License Selection Guide, and system software that may be used during the upgrade.

Equipment
3.2 Checking the Health Status of the ATN

This section describes how to verify whether the current status of the ATN meets the deployment
requirements.
Prerequisites
Procedure
Step 1 Run the display health command to view the health status of the ATN.
ATN 910/ATN 910I/ATN 910B:

<HUAWEI> display health
Slot CPU Usage Memory Usage(Used/Total)
---------------------------------------------------------
2 MPU(Master) 9% 21% 396MB/1823MB
ATN 950B:
<HUAWEI> display health
Slot CPU Usage Memory Usage(Used/Total)
---------------------------------------------------------
7 MPU(Master) 22% 44% 140MB/318MB
8 MPU(Slave) 11% 43% 139MB/318MB
If the CPU usage and memory usage of the boards on the ATN remain under 80%, as shown by
the percentages in boldface in the displayed information, go on with the subsequent
commissioning.
----End
Troubleshooting
In normal situations, CPU or memory usage should be lower than 80%.
If CPU or memory usage remains high before services are deployed in a large scale, contact
Huawei technical support personnel.
3.3 Checking the Board Registration Status

This section describes how to determine whether the boards are properly installed and function
normally.
Prerequisites

Equipment
Procedure
Step 1 Run the display device [ pic-status | slot-id ] command to view information about the
components installed on the ATN.
ATN 950B:
<HUAWEI> display device
ATN950B's Device status:
Slot # Type Online Register Status Primary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 PIC Present Registered Normal NA
7 CXP Present NA Normal Master
8 CXP Present Registered Normal Slave
9 PWR Present Registered Abnormal NA
10 PWR Present Registered Normal NA
11 FAN Present Registered Normal NA

<HUAWEI> display device
ATN910's Device status:
Slot # Type Online Register Status Primary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 CXP Present NA Normal Master
5 PWR Present Registered Abnormal NA
6 FAN Present Registered Normal NA
Pay attention to the Register and Status fields in the displayed information.
l Register field: indicates whether a component is successfully registered. The field value can
be NA, Registered, or Unregistered. NA indicates that the component must be used during
the ATN startup. Registered indicates that a component is successfully registered.
Unregistered indicates that a component is not registered.
l Status field: indicates the component status. The field value can be Normal or Abnormal.
If the Register field values are Registered or NA and the Status field values are Normal, as shown
by the characters in boldface in the preceding displayed information, go on with the subsequent
commissioning.
----End
Troubleshooting
If the board is not registered, perform the following operations:
1. Check that the start-up time of the board has expired.

The time required for a board to complete registration after it is powered on is called the
start-up time.
Wait until the start-up time expires. If the board is still unregistered when the start-up time
expires, go to next step.
2. Check that the board type is supported by the system software.

Equipment
Supported board types vary with system software versions. For the types of boards that are
supported by this software version, see the chapter titled "Boards" in the ATN Multi-service
Access Equipment Hardware Description.
If the board type is supported by this system software version but the board cannot be
registered, go to next step.
3. Check that the board has been powered on.
Check whether the power supply of the slot where the board resides is normal. If the
indicator on the board is on, the power supply of this slot is normal.
l If the power supply of the slot is abnormal, contact Huawei technical support personnel.
l If the power supply of the slot is normal but the system still informs that the board is
not powered on, the power module on the board is faulty. In this case, you need to
replace the board.
If the power supply of the board is normal but the board still cannot be registered, go to
next step.
4. If a new board cannot be registered, remove the board and then install it again. If the board
still cannot be registered, go to next step.
5. Collect the following information and contact Huawei technical support personnel:
l Configuration files, log files, and alarm files of the ATN. For more information, see
Maintenance Items and Operations to collect the information.
3.4 Checking the Fan Status

This section describes how to check whether fans function properly. By default, fans work in
auto adjusting mode. When the ambient temperature rises sharply, you can manually set it to
full speed mode to protect the device.
Prerequisites
Procedure
Step 1 Run the display fan command to check the fan status.
ATN 950B:
<HUAWEI> display fan
SlotID : 11
Present : YES
Registered: YES
Status : MANUAL
FanSpeed : [No.]Speed
: [1] 95%
: [2] 95%
: [3] 95%
: [4] 95%
: [5] 95%
: [6] 95%

Equipment
<HUAWEI> display fan

SlotID : 6
Present : YES
Registered: YES
Status : AUTO
FanSpeed : [No.]Speed
: [1] 50%
: [2] 50%
: [3] 50%
If fan modules are properly installed and successfully registered, as shown by the characters in
boldface in the displayed information, go on with the subsequent commissioning.
----End
The displayed information may be different in real-world situations. For more information, see
display fan.
3.5 Checking the Power Status

This section describes how to verify whether power modules function properly.
Prerequisites
Procedure
Step 1 Run the display power command to check the power status.

<HUAWEI> display power
No Present mode State Num
-------------------------------------------------------------------------------
5 Yes DC Normal 1
ATN 950B:
<HUAWEI> display power
No Present mode State Num
-------------------------------------------------------------------------------
9 Yes DC Normal 1
10 Yes DC Normal 1
If the power modules are properly installed and work normally as shown by the characters in
boldface in the displayed information, go on with the subsequent commissioning.
----End
The displayed information may be different in real-world situations. For more information, see
display power.

Equipment
3.6 Checking System Time

This section describes how to verify whether the system time meets the system requirements.
Prerequisites
Procedure
Step 1 Run the display clock command to view system time.
<HUAWEI> display clock
2010-10-31 19:16:14
Sunday
Time Zone(DefaultZoneName) : UTC
If the system time and time zone displayed in boldface in the preceding information are consistent
with the local time and time zone, go on with the subsequent commissioning.
----End
Troubleshooting
If the system time and time zone displayed in the display clock command output are inconsistent
with the local time and time zone, follow the procedure below to reconfigure the system time:
1. Run the clock datetime [ utc ] HH:MM:SS YYYY-MM-DD command in the user view to
set the Universal Time Coordinated (UTC).
2. Run the clock timezone time-zone-name { add | minus } offset command in the user view
to set the time zone based on an offset. (The ATN obtains the current system time by
subtracting an offset from or adding an offset to the UTC.)
3. (Optional) Run the clock daylight-saving-time time-zone-name repeating start-time
{ { { first | second | third | fourth | last } weekday month } | start-date } end-time
{ { { first | second | third | fourth | last } weekday month } | end-date } offset command
in the user view to set the daylight saving time.
3.7 Checking the Interface Status

This section describes how to verify the interface status.
Prerequisites
Procedure
Step 1 Run the display interface brief [ main ] command to view brief information about all interfaces
on the ATN. The information includes the physical status, protocol status, latest bandwidth usage
in the inbound or outbound direction, and number of received or transmitted incorrect packets.

Equipment
<HUAWEI> display interface brief

PHY: Physical
*down: administratively down
^down: standby
(l):loopback
(s):spoofing
(b):BFD down
(e):EFM down
(d):Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Eth-Trunk0 up up 3% 7% 12 0
GigabitEthernet0/2/0 up up 50% 60% 23 125
GigabitEthernet0/2/1 *down down 40% 30% 0 0
GigabitEthernet0/2/2 up up 0% 0% 0 0
GigabitEthernet0/2/3.1 up up 0% 0% 0 0
Ensure that the physical status and protocol status are Up.
----End
Troubleshooting
If the physical status is Down, perform the following operations:
1. Run the display this command on both the local and remote interfaces to check whether
they have been shut down. If either one of them or both of them have been shut down, run
the undo shutdown command in the interface view. After that, run the display this
interface command to check whether the interfaces have gone Up.
2. At this step, optical interfaces and electrical interfaces are handled differently.
l If optical interfaces are used for connection, skip this step.
Check that the fiber is properly installed. If the fiber is improperly installed, reinstall
the fiber. After that, run the display this interface command to check whether the
interface status is Up. If the fiber is properly installed but the interface status is Down,
perform the next step.
Check that the optical modules on the interfaces of the local match that of peer
devices, including interface types, wavelengths, and optical powers of optical
modules. If they are not matched, replace optical modules. Then, run the display
this interface command to check whether the interface status is Up.
l If electrical interfaces are used for connection, check that the network cable is properly
installed. If the network cable is improperly installed, reinstall the network cable. After
that, run the display this interface command to check whether the interface status is
Up. If the network cable is properly installed but the interface status is Down, perform
the next step.
3. If optical interfaces are used for connection, use a fiber or optical modules. If electrical
interfaces are used for connection, use a network cable or electrical modules. After that,
run the display this interface command to check whether the interface status is Up.
4. Run the display trapbuffer command to check whether interface-related alarms have been
generated. If such alarms have been generated, consult the Alarm Reference of the ATN.
5. If the physical status is still down, collect the following information and contact Huawei
technical support personnel:

Equipment
3.8 Checking Alarm Information

This section describes how to verify alarms and faults about the ATN.
Prerequisites
Procedure
Step 1 Run the display alarm { slot-id | all } command to view all alarms on the ATN to determine if
faults have occurred on the ATN.
<HUAWEI> display alarm all
----------------------------------------------------------------------------
NO alarm
----------------------------------------------------------------------------
If the preceding information is displayed, the hardware is not faulty. Otherwise, locate and rectify
any found fault based on the contents of the Info field in the command output.
Step 2 Run the display trapbuffer[ size value ] command to view alarms recorded in the trap buffer.
Pay attention to the important alarms.
<HUAWEI> display trapbuffer
Trapping Buffer Configuration and contents:enabled
allowed max buffer size : 1024
actual buffer size : 256
channel number : 3 , channel name : trapbuffer
dropped messages : 0
overwritten messages : 131
current messages : 1
#Nov 16 2010 15:33:06 HUAWEI SRM_BASE/1/ENTITYRESUME: OID 1.3.6.1.4.1.2011.5.25
.129.2.1.10 Physical entity is detected resumed from failure. (EntityPhysicalInd
ex=16908289, BaseTrapSeverity=2, BaseTrapProbableCause=67719, BaseTrapEventType=
5, EntPhysicalContainedIn=16908288, EntPhysicalName="LPU 7", RelativeResource="S
FP", ReasonDescription="LPU 7 is failed, EAGF SFP 0 of PIC0 is abnormal, Resume")
The part displayed in boldface in the preceding information indicates the alarm severity. Note
down the alarms and immediately handle the alarms whose alarm severities are 3 or higher.
----End

Equipment
Commissioning Guide 4 Commissioning the Link Layer
4 Commissioning the Link Layer
About This Chapter
This section describes how to commission the link layer when the ATN is connected to other
transport devices.
4.1 Checking Ethernet Interfaces

This section describes how to check the link layer on Ethernet interfaces.
4.2 Checking E-Carrier Interfaces

This section describes how to check the link layer on E-Carrier and T-Carrier interfaces. In this
section, a CE1 interface is used as an example.
4.3 Checking the Optical Power of Interfaces

This section describes how to verify whether the optical power of SFP optical modules meets
requirements.
4.4 Commissioning T1 Carrier Interfaces

This section describes how to ensure T1 carrier interfaces function properly. This section uses
the CT1 carrier interface as an example for illustration.
4.5 Commissioning XDSL Interfaces

This section describes how to ensure XDSL interfaces function properly.
4.6 Commissioning ATM Interfaces

This section describes how to commission ATM interfaces.
4.7 Commissioning TDM Interfaces

This section describes how to commission TDM interfaces.
4.8 Commissioning MP Interfaces

This section describes how to commission MP interfaces.

Equipment
4.1 Checking Ethernet Interfaces

This section describes how to check the link layer on Ethernet interfaces.
Prerequisites
l Hardware installation is complete. For more information, see 3 Checking the
Hardware.
Procedure
Step 1 Run the display interface ethernet brief command to view the physical status, auto-negotiation
mode, duplex mode, rate, and latest average inbound and outbound bandwidth usage of Ethernet
interfaces. For example:
<HUAWEI> display interface ethernet brief
PHY: Physical
*down: administratively down
^down: standby
(l): loopback
(b): BFD down
InUti/OutUti: input utility/output utility
Interface Physical Auto-Neg Duplex Bandwidth InUti OutUti
Trunk
GigabitEthernet0/2/0 up enable half 100M 0% 0%
--
GigabitEthernet0/2/1 up disable full 1000M 0% 0%
--
--
--
GigabitEthernet0/2/4 up disable full 1000M 0.01% 0.01%
--
--
In normal situations, the physical status of interfaces are up, as shown by the characters displayed
in boldface.
Step 2 Run the display interface command to view the MTU, IP address, mask, rate, and operation
mode of an Ethernet interface. For example:
<HUAWEI> display interface gigabitethernet 0/2/0
GigabitEthernet0/2/0 current state : UP
Line protocol current state : UP
Last line protocol up time : 2011-01-21 10:41:52
Description:HUAWEI, Quidway Series, GigabitEthernet0/2/0 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 192.168.1.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 286e-d446-92ee
The Vendor PN is RTXM191-400
The Vendor Name is WTD
Port BW: 1G, Transceiver max BW: 1G, Transceiver Mode: SingleMode
WaveLength: 1310nm, Transmission Distance: 10km
Rx Power: -1.79dBm, Tx Power: -5.42dBm
Loopback:none, full-duplex mode, negotiation: disable, Pause Flowcontrol:Receive
Enable and Send Enable
The setted port-tx-enabling delay time is: 0 ms
The remanent time of enabling port-tx is: 0 ms

Equipment
Last physical up time : 2011-01-21 10:18:36

Last physical down time : 2011-01-21 10:18:33
Current system time: 2011-01-21 17:38:09
Statistics last cleared:never
Last 300 seconds input rate: 1864 bits/sec, 0 packets/sec
Last 300 seconds output rate: 304 bits/sec, 0 packets/sec
Input: 3395338075388 bytes, 37029512796 packets
Output: 3249024483376 bytes, 36269651204 packets
Input:
Unicast: 37029263352 packets, Multicast: 248883 packets
Broadcast: 561 packets, JumboOctets: 0 packets
CRC: 1 packets, Symbol: 0 packets
Overrun: 0 packets, InRangeLength: 0 packets
LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets
Fragment: 0 packets, Undersized Frame: 0 packets
RxPause: 0 packets
Output:
Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
System: 0 packets, Overrun: 0 packets
TxPause: 0 packets
Input bandwidth utilization : 0.01%
Output bandwidth utilization : 0.01%
In normal situations, the physical status and protocol status of an Ethernet interface are up, and
the link status on the local end are the same as that on the peer end, as shown by the characters
displayed in boldface.
Step 3 Run the ping command to test Ethernet link connectivity. For example:
<HUAWEI> ping 192.168.1.2
PING 192.168.1.2: 56 data bytes, press CTRL_C to break
Reply from 192.168.1.2: bytes=56 Sequence=1 ttl=255 time=2 ms
--- 192.168.1.2 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/23/113 ms
In normal situations, the ping operation should succeed.
----End
Troubleshooting
l If the physical status of an Ethernet interface is Down after the interface is configured,
perform the following operations:
1. Check that the peer device is started. If the peer device is not started, start it.
2. Run the display interface interface-type interface-number command to view the
optical module information and interface configurations on the local and peer ends.
Check that the optical modules on the local and peer interfaces are matched,
including interface types, rate, wavelengths, and optical powers of optical modules.
Check the fiber connected the optical modules and the power of connected optical
modules meet the requirement. If the fiber or either of the optical modules does
not meet the requirement, replace it.

Equipment
Check that the interface configurations such as the MTU, TTL of packets, format
of transmitted Ethernet frames, and maximum QoS bandwidth on the local and
peer ends are consistent. If they are inconsistent, adjust them to ensure consistency.
Check that the traffic is normal.
3. Check that the fiber is properly and correctly installed. This means that the fiber is
connected to the correct transmit optical module and receive optical module.
4. Perform self-loop detection on interfaces to check whether the interfaces are normal.
After you run the undo shutdown command in the interface view, connect the RX
end and TX end of an optical module on the local interface using a fiber. Check
whether the interface is Up. If the interface is Up, the local interface is normal. Perform
the same operation on the remote interface. If the remote physical layer is Up, the
remote interface is normal. You need to replace the fiber.
5. If the fault persists after the preceding operations are complete, contact Huawei
technical support personnel.
l If an Ethernet interface cannot be pinged, perform the following operations:
1. Check that the local end is correctly connected to the peer end. Observe the Link
indicator on the NPU where the local Ethernet interface resides. If the indicator is on,
the link works properly. If the indicator is off, check the optical module, interface,
fiber, and the device.
2. Check that the auto-negotiation modes on the local and peer Ethernet interfaces are
consistent.
3. Check that the IP address of the local Ethernet interface belongs to the same subnet
as that of the peer Ethernet interface. This means that the two IP addresses must have
the same network address and different host addresses. If the two IP addresses do not
belong to the same subnet, reconfigure the IP addressesand the masks.
4. If the fault persists after the preceding operations are complete, contact Huawei
technical support personnel.
4.2 Checking E-Carrier Interfaces

This section describes how to check the link layer on E-Carrier and T-Carrier interfaces. In this
section, a CE1 interface is used as an example.
Prerequisites
Hardware.
Procedure
Step 1 Run the display controller e1 command to check the status of a CE1 interface. For example:
<HUAWEI> display controller e1 0/2/0
E1 0/2/0 current state : UP
Description : HUAWEI, Quidway Series, E1 0/2/0 Interface
Physical layer is Packet Over NO-CRC4
clock master, linecode hdb3 , loopback none
Alarm: none

Equipment
As shown by the characters displayed in boldface, the CE1 interface status is UP when the CE1
interface is correctly configured, and no alarms or errors are displayed.
Step 2 Run the display interface serial command to view the operating status of and statistics on the
serial interface. For example:
<HUAWEI> display interface serial 0/2/0/0:0
Serial0/2/0/0:0 current state : Up
Line protocol current state : Up
Description:HUAWEI, Quidway Series, Serial0/2/0/0:0 Interface
Route Port,The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
Derived from CPOS 0/2/0 e1 1, Timeslot(s) Used: 1-31, baudrate is 1984000 bps
Internet protocol processing : enabled
Link layer protocol is PPP
LCP initial
clock master, loopback none
CRC: CRC-32
Framer LOS Alarm Status(0-NONE 1-ALARM): 0
Framer LOF Alarm Status(0-NONE 1-ALARM): 1
Framer PAIS Alarm Status(0-NONE 1-ALARM): 1
Framer PRDI Alarm Status(0-NONE 1-ALARM): 0
PSN2TDM PW Alarm status(0-NONE 1-RDI 2-AIS): 0
Statistics last cleared:2011-01-21 10:18:07 09:25:21
Traffic statistics:
Input: 0 packets
Output: 0 packets
Output error:
0 underrun count, 0 overrun count
0 misorder packets, 0 malformed packets
0 los packets, 0 dummy packets
ES: 0, SES: 0, UAS: 0
As shown by the characters displayed in boldface, the physical status and link layer protocol
status of the serial interface are Up when the serial interface channelized from a CE1 interface
is correctly configured. If the IP addresses of the serial interfaces on both ends of the link and
routes are correctly configured, the network layer protocol status on the local serial interface is
enabled.
Step 3 Run the ping command to test CE1 link connectivity. For example:

0.00% packet loss
In normal situations, the ping operation should succeed.
----End
Troubleshooting
If E-carrier interfaces on both ends of a link cannot communicate with each other after the
interfaces are configured, perform the following operations:

Equipment
1. Check that the physical layer is Up.
a. Run the display controller e1 command to view interface information on each end.
If the physical status is displayed as Administratively Down, the shutdown
command has been run on the interface. Run the undo shutdown command to enable
the interface.
If the physical status is displayed as Down, check the following items:
l Fiber is properly connected to the local interface and the indicator for the interface
is in a normal state.
l Fiber is properly connected to the peer interface. Run the display this interface
command in the interface view to check if the physical status of the peer interface
is Administratively Down and if loopback is configured on the peer interface.
l Interface configurations, such as the operation mode and line coding/decoding
format, on the two ends are consistent, and the clock modes configured on the two
ends are correct.
b. If the fault persists, run the loopback command in the CE1 interface view.
If the physical status of the interface is Up, the hardware on the local end works
properly. The problem lies in the cable, and you need to replace the cable. If the
physical status of the interface is Down, the board where the interface resides is faulty.
The board needs to be repaired.
2. Check that the link layer is Up.
If the link status is Down, run the display interface serial command on each end to check
the link status.
a. Check whether the two ends use the same link layer protocol. The link layer can go
Up only when the two ends of the link use the same link layer protocol.
b. If the physical layer is Up, check whether correct IP addresses are configured for the
interfaces on the two ends.
c. If the LCP negotiation status is not opened, LCP negotiation has not been completed
yet. LCP negotiation is completed only when the LCP negotiation status is opened.
d. If the LCP negotiation status is opened and the IPCP negotiation status is not opened,
IPCP negotiation has not been completed. IPCP negotiation is completed only when
the IPCP negotiation status is opened.
3. If the interfaces on the two ends of the link still cannot ping each other even if all
configurations are correct, run the display interface serial command to view statistics on
the interfaces and contact Huawei technical support personnel.
4.3 Checking the Optical Power of Interfaces

This section describes how to verify whether the optical power of SFP optical modules meets
requirements.
You need to check whether the optical power of SFP optical modules meets requirements. If the
output optical power of SFP optical modules does not meet requirements, packets will be lost
and communication will be interrupted on the network layer.

Equipment
Prerequisite
Hardware.
Procedure
Step 1 Run the display interface interface-type interface-number command to view the operating
status and statistics on each of two connected interfaces. Go on with the subsequent
commissioning, if the maximum transmission distance and central wavelength of the optical
modules on the two connected interfaces are consistent and the input optical power and output
optical power of the optical modules are within the allowed range.
NOTE
The display this interface command can also be run in the interface view to display interface information. The
output of the display interface command and that of the display this interface command are the same.
<HUAWEI> display interface gigabitethernet 0/2/0
GigabitEthernet0/2/0 current state : UP
Description:HUAWEI, Quidway Series, GigabitEthernet0/2/0 Interface
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 286e-d446-92ee
The Vendor PN is RTXM191-400
The Vendor Name is WTD
Port BW: 1G, Transceiver max BW: 1G, Transceiver Mode: SingleMode
WaveLength: 1310nm, Transmission Distance: 10km
Rx Power: -1.79dBm, Tx Power: -5.42dBm
Loopback:none, full-duplex mode, negotiation: disable, Pause Flowcontrol:Receive
Enable and Send Enable
The setted port-tx-enabling delay time is: 0 ms
The remanent time of enabling port-tx is: 0 ms
Last physical up time : 2011-01-21 10:18:36
Last physical down time : 2011-01-21 10:18:33
Last 300 seconds input rate: 1864 bits/sec, 0 packets/sec
Last 300 seconds output rate: 304 bits/sec, 0 packets/sec
Input: 3395338075388 bytes, 37029512796 packets
Output: 3249024483376 bytes, 36269651204 packets
Input:
CRC: 1 packets, Symbol: 0 packets
Overrun: 0 packets, InRangeLength: 0 packets
LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets
Fragment: 0 packets, Undersized Frame: 0 packets
RxPause: 0 packets
Output:
Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
System: 0 packets, Overrun: 0 packets
TxPause: 0 packets
Check boldfaced items displayed and ensure that the interface bandwidth, fiber mode, maximum
transmission distance, and central wavelength of the optical module are the same as that of its
connected optical module on the peer end. Check the output optical power of optical modules

Equipment
on the two ends against the "List of LPU Interface Attributes" to determine if the input optical
power is within the allowed range.
NOTE
See "List of LPU Interface Attributes" in the appendix. To use the optical module on the local end, the following
two conditions for the input optical power of the optical module must be met:
l The input optical power must be greater than the receiver sensitivity of the optical module (3dBm).
Otherwise, the peer end will not receive any signals.
l The input optical power must be lower than the overload optical power (3dBm). Otherwise, the optical
module may be damaged.
----End
Troubleshooting
If the output optical power of an optical module is beyond the allowed range, replace the optical
module.
4.4 Commissioning T1 Carrier Interfaces

This section describes how to ensure T1 carrier interfaces function properly. This section uses
the CT1 carrier interface as an example for illustration.
Prerequisites
Hardware commissioning has been completed and the ATN device to be commissioned is
running properly.
NOTE
Only the ATN 910 supports T1 interface.
Context
As shown in Figure 4-1, a static routing protocol has to be deployed in the network to ensure
normal communication between the ATN device and the network segment 192.167.1.0 where
the CX600B is located.
Figure 4-1 Typical networking diagram for T1 carrier interface commissioning
1.1.1.1/3 2.2.2.2/3
2 2
192.168.1.1 / 24
Console T1 0/3/0
network
T1 1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B

Equipment
Procedure
Step 1 On the ATN device, run the display controller t1 command to check the CT1 interface status.
<HUAWEI> display controller t1 0/3/0
T1 0/3/0 current state : UP
Description : HUAWEI, T1 0/3/0 Interface
Physical layer is Packet Over ESF
clock master, linecode b8zs, loopback none
lbo none, cablelength short 0-133 feet
Alarm: none
As shown in the command output, the CT1 interface should be up and there should be no alarms
or errors on the link.
----End
Handling Common Faults

After the T1 interface is configured, the interface state is down or alarms are reported for the
interface. The following describes the fault handling procedure for each possible cause.
1. Cause 1: The T1 interface is shut down.
Handling procedure:
a. Run the display this interface command to view the basic configurations of the T1
interface.
[HUAWEI-T1 0/3/0]display this interface
T1 0/3/0 current state : Administratively DOWN
Alarm: LAIS
If the interface is shut down, "Administratively DOWN" is displayed in the first row
of the command output. In this situation, run the undo shutdown command to the
interface to turn on the interface. After that run the previous command to check the
interface configurations again. If the interface has been shut down, the interface state
should change to up after you run the undo shutdown command. If the interface state
remains down, see the fault handling procedure for cause 2 or 3.
2. Cause 2: Alarms have been reported for the interface.
Handling procedure:
a. In the T1 interface view, run the display this interface command to view the alarm
information.
T1 0/3/0 current state : DOWN
Alarm: LOF
b. If a LOF alarm is displayed in the command output, the channelized mode or frame
format for the T1 interface is inconsistent with that of the connected interface. Correct
the settings make the channelized modes or frame formats consistent for the two
interfaces.
c. If a LOS alarm is displayed in the display this interface command output, check
whether the specified lbo and cablelength values are consistent with the actual

Equipment
physical cable type and length. If not, correct the settings to make them consistent. If
the LOS alarm persists after you correct the settings, the physical line is faulty. See
the fault handling procedure forfor cause 3.
d. If an LAIS or LRDI alarm is reported for the interface and the alarm has been
configured as a condition for the interface to become down, handle the alarm by
referring to the procedures for handling link layer protocol faults. Then determine
whether to disable the alarm from being a condition for the interface to enter the down
state depending on the actual situation.
[HUAWEI-T1 0/3/0]display this
#
controller T1 0/3/0
channel-set 1 timeslot-list 0-23
undo shutdown
transmission-alarm down lais lrdi
#
return
3. Cause 3: The T1 interface is connected incorrectly, the T1 cable or the interface is damaged.
Handling procedure:
a. In the T1 interface view, run the display this interface command to view the basic
configurations of the T1 interface.
T1 0/3/0 current state : DOWN
Alarm: LOS
If a LOS alarm has been reported for the interface, then no signal is sent to the interface.
b. Perform a loopback on the T1 interface by running the loopback command to check
whether the T1 interface state will change to up.
NOTE
The interface loopback mode is associated with the interface clock mode. To be more specific, clock
master corresponds to loopback local and clock slave corresponds to loopback remote. Therefore,
when running the loopback command, ensure that the correct loopback mode is used for the
corresponding clock mode.
The following figure shows the loopback modes and the following table describes the
loopback modes.
Figure 4-2 Loopback schematic diagrams for the T1 interface

Equipment
Loopback Description
Mode
loopback local In the loopback local mode, a local signal is transmitted by the
Tx interface to the Rx interface to determine whether the local
T1 line is normal. If the physical state of the local T1 interface
changes to up after you run the loopback local command, then
the local T1 line is damaged or the T1 interface is damaged.
loopback remote In the loopback remote mode, a signal received by the Rx

interface is directly sent to the Tx interface to determine
whether the T1 line from the remote T1 interface to the local
T1 interface is normal. If the physical state of the remote T1
interface changes to up after you run the loopback remote
command, then the T1 line from the remote T1 interface to the
local T1 interface is normal. Otherwise, the T1 line between
the two T1 interfaces is damaged or the connection between the
two T1 interfaces is incorrect.
Select the required loopback on the T1 interface. If the T1 interface becomes up after
the loopback is performed and the configurations for the local and remote T1 interfaces
are the same, the T1 cable between the two interfaces is connected incorrectly or the
T1 interface is in poor contact. Check whether the T1 cable is connected correctly. If
not, correct the connection. If so, the T1 cable is damaged, so replace the T1 cable. If
the connection is correct and the physical state of the T1 interface is still down after
the loopback is performed, some physical component on the T1 interface is damaged.
In this situation, contact Huawei technical support engineers.
4.5 Commissioning XDSL Interfaces

This section describes how to ensure XDSL interfaces function properly.
Prerequisites
Hardware commissioning has been completed and the ATN device to be commissioned is
running properly.
NOTE
Only the ATN 910 supports XDSL interface.
Context
the DSLAM is located.

Equipment
Figure 4-3 Typical networking diagram for XDSL interface commissioning
1.1.1.1/3 2.2.2.2/3
2 2
192.168.1.1 / 24
Console DSL0/4/0
network
DSL0/3/0 GE0/3/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA DSLAM
Procedure
Step 1 On the ATN device, run the display interface brief command to view the status of the dsl-group
and VE interfaces on the ATN device.
<HUAWEI> system
[HUAWEI] display interface brief
PHY:
Physical
*down: administratively
down
(l):
loopback
(s):
spoofing
(b): BFD
down
(e): ETHOAM
down
(d): Dampening
Suppressed
InUti/OutUti: input utility/output

utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Dsl-group0/4/0 up up 0% 0% 0 0
Virtual-Ethernet0/4/0 up down 0% 0% 0
0
Virtual-Ethernet0/4/0.1 up up 0% 0% 0
0
0
0
Virtual-Ethernet0/4/0.7 up down 0% 0% 0
0
0
Virtual-Ethernet0/4/1 up down 0% 0% 0 0
Xdsl0/4/0 up up 0% 0% 0
0
Xdsl0/4/1 up up 0% 0% 0
0
Xdsl0/4/2 up up 0% 0% 0

Equipment
0
Xdsl0/4/3 up up 0% 0% 0 0
If the physical state of the dsl-group interface is not up, check whether the ATN device
configuration matches the DSLAM configurations. If not, correct the ATN device configuration
accordingly. If the physical state of the dsl-group interface is up while the physical state of the
Virtual-Ethernet interface is down, then the dsl-group interface is not bound to a VE. In this
case, bind the dsl-group interface to a VE.
----End

N/A
4.6 Commissioning ATM Interfaces

This section describes how to commission ATM interfaces.
Prerequisites
Hardware commissioning has been completed, the ATN device to be commissioned is running
properly, and the E1 cables on the AC sides of the ATM link are correctly connected.
Context
Figure 4-4 Typical networking diagram for ATM interface commissioning

Legacy 2G
BTS
BSC/RNC
Voice and Data

Over TDM CX600B
n * E1
n * E1
ATNA
3G BTS CBSC
EVDO-R0/REV
A/REV B

Equipment
Procedure
Step 1 Run the channel-set command to an E1 interface to configure timeslots for the interface. Then
create a serial interface and specify the protocol as ATM for the interface. Determine whether
to configure scrambling for the ATM link according to the actual situation. The following uses
serial interfaces 0/2/0:1 and 0/2/1:1 as examples to describe how to scramble or descramble
ATM links.
Step 2 Configure an IMA interface and set attributes for the IMA interface, such as the IMA frame
length, differential delay, and minimum number of active links.
Step 3 Add the ATM links to the IMA group. For the detailed procedure, see the guides to configure
ATN ATM and IMA interfaces. Then run the display this command on the ATN device to view
the configurations of the serial interfaces.
[HUAWEI-Serial0/2/0:1] display this
#
interface Serial0/2/0:1
link-protocol atm
ima ima-group 0/2/1
#
return
On the ATN device, run the display this command to the view the configurations of the IMA
interface.
[HUAWEI-Ima-group0/2/1] display this
#
interface Ima-group0/2/1
#
return
On the ATN device, run the display this interface command to check the status information for
the IMA group.
[HUAWEI-Ima-group0/2/1] display this interface
Ima-group0/2/1 current state :
UP
Line protocol current state :
UP
Description:HUAWEI, Ima-group0/2/1
Interface
Route Port,The Maximum Transmit Unit is
1500
VCs on main-interface: 0 (Total VCs:
0)
VPs on main-interface: 0 (Total VPs:
0)
Current system time: 2012-04-24
11:25:36
Physical layer is ATM over

IMA
IMA-clock: CTC, differential-delay-maximum: 25, active-links-minimum:

1
frame-length: 128, symmetry: symmetrical configuration and
operation
IMA_GRP_NE_STATE: operational, IMA_GRP_FE_STATE:
operational
IMA links: 2, First link:

Serial0/2/1
:
1

Equipment
Link
Serial0/2/1
:
1
Ne Tx state :
ACTIVE
Ne Rx state :
ACTIVE
Fe Tx state :
ACTIVE
Fe Rx state :
ACTIVE
Alarm:
NONE
Defect:
NONE
Link
Serial0/2/0
:
1
Ne Tx state :
ACTIVE
Ne Rx state :
ACTIVE
Fe Tx state :
ACTIVE
Fe Rx state :
ACTIVE
Alarm:
NONE
Defect:
NONE
Last 300 seconds input rate 0 bits/sec, 0 cells/

sec
Last 300 seconds output rate 0 bits/sec, 0 cells/
sec
Input: 0 cells, 0 bytes, 0 Errs, 0
CRC
Output: 0 cells, 0
bytes
Input bandwidth utilization :

0%
Output bandwidth utilization : 0%

Equipment
On the CX600, use the same way to configure the timeslots for the E1 link and add the timeslots
to the IMA group. Then specify the state of the ATM links as active and the state of the IMA
group as operational.
Step 4 Configure an ATM sub-interface, an IMA sub-interface, or a bundle interface. Then configure
a PVC and a PWE3 service for the interface. To configure an ATM-bundle interface, see the
Configuration Guide.
Do as follows to check the configurations of the IMA sub-interface.
On the ATN device, run the display this command to the view the configurations of the IMA
interface.
[HUAWEI-Ima-group0/2/1.1] display this
#
interface Ima-group0/2/1.1
pvc 10/10
map pvc 11/11 bidirectional
mpls l2vc 2.2.2.2 pw-template 1 103
#
return
On the ATN device, run the display mpls l2vc command to check the status of the PW.
[HUAWEI] display mpls l2vc interface Ima-group 0/2/1.1
*client interface : Ima-group0/2/1.1 is up
Administrator PW : no
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 103
VC type : ATM Nto1 VCC
destination : 2.2.2.2
local group ID : 0 remote group ID : 0
local VC label : 32 remote VC label : 28
max ATM cells : 28
ATM pack overtime : 1000 microseconds
seq-number : disable
transmit ATM cells : --
local AC OAM State : up
local PSN OAM State : up
local forwarding state : forwarding
local status code : 0x0
remote AC OAM state : up
remote PSN OAM state : up
remote forwarding state: forwarding
remote status code : 0x0
ignore standby state : no
BFD for PW : unavailable
VCCV State : up
manual fault : not set
active state : active
forwarding entry : exist
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
PW APS ID : 0
PW APS Status : --
TTL Value : 1
link state : up
local ATM cells : 28 remote ATM cells : 28
local VCCV : alert ttl lsp-ping bfd
remote VCCV : alert ttl lsp-ping bfd
local control word : disable remote control word : disable
tunnel policy name : tp31
PW template name : 1

Equipment
primary or secondary : primary

load balance type : flow
Access-port : false
Switchover Flag : false
VC tunnel/token info : 1 tunnels/tokens
NO.0 TNL type : cr lsp, TNL ID : 0x3
Backup TNL type : lsp , TNL ID : 0x0
create time : 0 days, 0 hours, 0 minutes, 11 seconds
up time : 0 days, 0 hours, 0 minutes, 11 seconds
last change time : 0 days, 0 hours, 0 minutes, 11 seconds
VC last up time : 2012/04/28 16:46:06
VC total up time : 0 days, 0 hours, 0 minutes, 11 seconds
CKey : 9
NKey : 1
PW redundancy mode : frr
AdminPw interface : --
AdminPw link state : --
Diffserv Mode : pipe
Service Class : ef
Color : green
DomainId : --
Domain Name : --
----End

An ATM interface is faulty.
1. Cause 1: The AC-side interfaces that carry the ATM service are not up. These interfaces
include the E1, serial, and IMA interfaces.
Handling procedure:
a. In the system view, run the display interface brief command to check the status of
the ATN service interfaces. If the physical state and protocol state of the interfaces
are up, see the fault handling procedure for cause 2.
b. If the sub-interfaces or the main interfaces are shut down (the physical state of these
interfaces are displayed as down), enter the interface view and run the undo
shutdown command to turn on the sub-interfaces or interfaces.
c. If the physical state of the serial interface is down, then the E1 interface is not up.
Handle the E1 interface fault.
d. If the physical state of the serial interface is up but the protocol state is down, in the
serial interface view run the display this command to check whether the protocol type
of the serial interface is ATM. If it is not ATM, change it to ATM. In the E1 interface
view, run the display this command to check whether the timeslot configurations
specified by the channel-set command for the E1 interface on the ATN device are
consistent with the timeslot configurations for the E1 interface on the CX600. If they
are inconsistent, correct the configurations.
e. If the interface for which ATM services are created belongs to an IMA group and the
physical state or protocol state of the IMA group is down, see the procedure for
handling an IMA group being down.
2. Cause 2: The PW or tunnel carrying the ATM service is down.
Handling procedure:

Equipment
a. In the system view, run the display mpls l2vc command to view the status of the PW
where the ATM service is interrupted. If the VC is up, see the fault handling procedure
for cause 3.
b. If the VC is down, check whether the VC ID, VC type, and control word of the ATN
device are consistent with those of the CX600. If they are inconsistent, correct the
configurations. Note that the VC ID and control word can be manually specified but
the VC type is determined by the sub-interface type (P2P or P2MP) and the connection
type (PVC or PVP).
c. If they are consistent but the VC is down, handle the fault by referring to the MPLS
fault handling procedure.
3. Cause 3: The MAP PVC or MAP PVP on the ATN device is inconsistent with that on the
CX600.
Handling procedure:
a. In the sub-interface view, run the display this command to retrieve the MPA PVC
value of the PVC or the MAP PVP value of the PVP and compare the value with that
of the CX600. If the values are the same, see the fault handling procedure for cause
4.
b. If the values for the ATN device and CX600 are different, change the value of the
ATN device or CX600 to the required value.
c. If they are the same but the VC is down, handle the fault by referring to the MPLS
4. Cause 4: The board hardware is faulty, or the board fails to function properly because of
an excessively high ambient temperature.
Handling procedure:
a. In the system view, run the display temperature command to check whether the board
temperature exceeds the upper threshold. If this is the case, replace the board.
b. If the service is still interrupted, collect the diagnose log and other logs of the ATN
device and collect the fault data using the one-click fault data collection function. Send
the logs and fault data to Huawei for further fault diagnosis.
The IMA group is down.

1. Cause 1: The IMA group has been shut down manually.
Handling procedure: In the IMA group view, run the display this command to view the
buildrun information. If shutdown is displayed in the buildrun, run the undo shutdown
command. Otherwise, see the fault handling procedure for cause 2.
2. Cause 2: No active link is available.
Handling procedure:
a. In the system view, run the display interface brief command to check the IMA group
status. If the physical and protocol states of at least one link in the IMA group are up,
then there are active links. In this case, see the fault handling procedure for cause 3.
b. If the physical state is displayed as *down for all the links in the IMA group, then the
serial interface has been shut down manually. Enter the serial interface view and run
the undo shutdown command.
c. If the physical state is displayed as down for all the links in the IMA group, then the
E1 line is faulty. Handle the fault by referring to the E1 fault handling procedure.

Equipment
d. If the physical state is up but the protocol state is down for all the links in the IMA
group, check whether the E1 line on the ATN device and CX600 is bound to an IMA
group. If you cannot check the configurations of the CX600, remove the links from
the IMA group on the ATN device and change the scrambling setting (scramble or
undo scramble) or the timeslot setting (1-31 or 1-15,17-31) for the IMA group. After
that, add the links to the IMA group again and check whether the protocol is up. If the
protocol on the ATN device cannot go up after the preceding operations, then the
configurations of the CX600 contain errors.
3. Cause 3: The number of active links is smaller than the number of activated links.
Handling procedure:
a. In the IMA group view, run the display this interface command to view the IMA
group information. In the command output, if "IMA_GRP_NE_STATE" is displayed
as "insufficientLinks", change the min-active-links value of the IMA group to a
smaller value or bind the IMA group to other links.
b. If the IMA group is still down, collect the diagnose log and other logs of the ATN
device and collect the fault data using the one-click fault data collection function. Send
the logs and fault data to Huawei for further fault diagnosis.
The ATM bundle interface is down.
1. Cause 1: The bundle interface has no member interface.

Handling procedure: Run the display current-configuration command to check whether
a sub-interface is added to the bundle interface. If no sub-interface is present, add the sub-
interface to the bundle interface.
2. Cause 2: All member interfaces in the bundle interface are down.
Handling procedure:
a. Determine which sub-interfaces that the bundle interface must contain.

b. Run the display interface brief command to check the status of the sub-interfaces. If
the sub-interfaces are all down, determine the causes and handle the fault accordingly.
4.7 Commissioning TDM Interfaces

This section describes how to commission TDM interfaces.
Prerequisites
properly, the E1 cables on the AC sides for carrying TDM services are correctly connected, and
network-side cables are connected correctly.
Context

Equipment
Figure 4-5 Typical networking diagram for TDM interface commissioning

Legacy 2G
BTS
BSC/RNC
Voice and Data

Over TDM CX600B
n * E1
n * E1
ATNA
Data
Over ML-PPP/ATM
3G BTS CBSC
EVDO-R0/REV
A/REV B
Procedure
Step 1 Configure a TDM serial interface and specify the protocol of the interface as TDM. The
following uses serial interface 0/2/2:1 as an example to describe how to configure a TDM serial
interface.
Step 2 Configure a TDM PWE3 service for the serial interface.

For the detailed procedure, see the guides to configure TDM services for ATN devices. Then
run the display this command on the ATN device to view the configurations of the serial
interface.
#
link-protocol tdm
#
return
On the CX600 device, use the same way to configure a TDM PWE3 service for the serial
interface. Ensure that the PW profile parameters of the CX600 are consistent with those of the
ATN device.
Step 3 On the ATN device, run the display mpls l2vc command to check the status of the TDM PW.
[HUAWEI] display mpls l2vc inter serial 0/2/2:1
*client interface : Serial0/2/2:1 is
up
Administrator PW :
no
session state :
up
AC status :
up

Equipment
VC state :
up
Label state :
0
Token state :
0
VC ID :
101
VC type : CESoPSN basic

mode
destination :
2.2.2.2
local group ID : 0 remote group ID :

0
local VC label : 16 remote VC label :
20
local TDM Encap Num : 8 remote TDM Encap Num :
8
jitter-buffer :
4
idle-code :
ff
local rtp-header : disable remote rtp-header :

disable
local bit-rate : 31 remote bit-rate :
31
local AC OAM State :
up
local PSN OAM State :

up
local forwarding state :

forwarding
local status code :

0x0
remote AC OAM state :

up
remote PSN OAM state :

up
remote forwarding state:

forwarding
remote status code :

0x0
ignore standby state :

no
BFD for PW :
unavailable

Equipment
VCCV State :
up
manual fault : not

set
active state :
active
forwarding entry :
exist
OAM Protocol :
--
OAM Status :
--
OAM Fault Type :

--
PW APS ID :
0
PW APS Status :
--
TTL Value :
1
link state :
up
local VC MTU : -- remote VC MTU :

--
local VCCV : alert ttl lsp-ping
bfd
remote VCCV : alert ttl lsp-ping
bfd
local control word : disable remote control word :
disable
tunnel policy name :
tp31
PW template name :
1
primary or secondary :
primary
load balance type :

flow
Access-port :
false
Switchover Flag :
false
VC tunnel/token info : 1 tunnels/

tokens
NO.0 TNL type : cr lsp, TNL ID :
0x3
Backup TNL type : lsp , TNL ID :
0x0
create time : 0 days, 4 hours, 42 minutes, 2

Equipment
seconds
up time : 0 days, 0 hours, 3 minutes, 59
seconds
last change time : 0 days, 0 hours, 3 minutes, 59
seconds
VC last up time : 2012/04/28
14:44:27
VC total up time : 0 days, 0 hours, 3 minutes, 59
seconds
CKey :
2
NKey :
1
PW redundancy mode :
frr
AdminPw interface :
--
AdminPw link state :

--
Diffserv Mode :
pipe
Service Class :
ef
Color :
green
DomainId :
--
Domain Name : --
As shown in the command output, the interface configurations and cable connections are correct,
no alarms are reported for the interface, and the PW is up. In addition, after a test instrument
feeds a service to the ATN device, the service is transmitted properly.
----End

The PW profile parameters of the ATN device are inconsistent with those of the CX600.
1. Handling procedure:
a. Run the display pw-template command on the ATN device and the CX600 to check
whether the PW profile parameters are consistent. If they are inconsistent, make
changes properly to make them consistent.
b. [HUAWEI] display pw-template
PW Template Name : 1
PeerIP : --
Tnl Policy Name : --
CtrlWord : Disable
MTU : 1500
Max Atm Cells : 28
ATM Pack Overtime: 1000
Seq-Number : Disable
TDM Encapsulation Number: 8
Jitter-Buffer : 4
Idle-Code : ff

Equipment
Rtp-Header : Disable
VCCV Capability : alert ttl lsp-ping bfd
Behavior Name : --
Total PW : 0, Static PW : 0, LDP PW : 0
The AC-side interfaces that carry TDM services are not up. These interfaces include the
E1 and serial interfaces.
1. Handling procedure 1:
a. In the E1 interface view, run the display this interface command to check whether
the physical state of the interface is up. If the state is not up, handle the fault of the E1
interface being down.
b. In the serial interface view, run the display this interface command to check whether
the serial interface has been shut down. If the serial interface has been shut down, run
the undoshut serial command to turn on the interface.
c. In the serial interface view, run the display this command separately on the ATN
device and the CX600 to check whether the TDM protocol is used on the two devices.
If it is not, correct the setting to ensure that the two devices use the TDM protocol.
#
link-protocol tdm
#
return
For the E1 interfaces on the ATN device and CX600, the channelized mode or the number
of bound timeslots differs.
a. In the E1 interface view, run the display this command on the ATN device and the
CX600 separately to view the channelized mode and number of bound timeslots
configured for the E1 interfaces. If the configurations are inconsistent, correct them.
[HUAWEI-E1 0/2/2] display this
#
controller E1 0/2/2
channel-set 1 timeslot-list 1-31
undo shutdown
#
return
An example is as follows:
[PPP_950-E1 0/2/1]display this
#
controller E1 0/2/1
using e1
undo shutdown
#
return
The PW or tunnel that carries the TDM service is down.

1. Handling procedure: On the ATN device, run the display mpls l2vc command to check
the PW status of the port where the service is interrupted.
[HUAWEI] display mpls l2vc inter serial 0/2/2:1
*client interface : Serial0/2/2:1
Administrator PW : no
session state : down
AC status : up
VC state : down
Label state : 0

Equipment
Token state : 0
VC ID : 101
VC type : SAT E1 over Packet
control word : disable
TDM encapsulation number : 8
jitter-buffer : 4
idle-code : ff
rtp-header : disable
forwarding entry : not exist
local group ID : 0
active state : inactive
link state : down
local VC MTU : 2000 remote VC MTU : 0
tunnel policy name : --
traffic behavior name: --
PW template name : 1
load balance type : flow
Access-port : false
VC last up time : 0000/00/00 00:00:00
CKey : 4
NKey : 3
Diffserv Mode : pipe
Service Class : ef
Color : green
DomainId : --
Domain Name : --
a. If the AC status is displayed as down in the command output, see the fault handling
procedure for cause 3. If the session state is displayed as down, handle the fault by
referring to the MPLS fault handling procedure.
b. If the AC status and the session state are displayed as up but the VC is down, check
whether the VC ID, VC type, and control word of the ATN device are consistent with
those of the CX600.
c. If they are inconsistent, make changes properly to make them consistent. If they are
consistent but the VC is down, handle the fault by referring to the tunnel fault handling
procedure.
2. Handling procedure 2:
a. Check whether the QoS is configured for the network interface. If QoS is configured,
handle the fault by referring to the QoS fault handling procedure.
b. If the physical state of the TDM link is displayed as *down, then the serial interface
has been shut down manually. Enter the serial interface view and run the undo
shutdown command.
c. If the physical state of the TDM link is displayed as down, then the E1 line is faulty.
Handle the fault by referring to the E1 fault handling procedure.
d. If the physical state is up but the protocol state is down, check whether the E1 line on
the ATN device and CX600 is bound to an IMA group If you cannot check the
configurations of the CX600, remove the links from the IMA group on the ATN device
and change the scrambling setting (scramble or undo scramble) or the timeslot setting

Equipment
(1-31 or 1-15,17-31) for the IMA group. After that, add the links to the IMA group
again and check whether the protocol is up. If the protocol on the ATN device cannot
go up after the preceding operations, then the configurations of the CX600 contain
errors.
The bandwidth allocated to the TDM service on the NNI side is insufficient, or the service
packets of a higher priority occupied the bandwidth allocated to the TDM service.
a. Check whether the QoS is configured for the network interface. If QoS is configured,
handle the fault by referring to the QoS fault handling procedure.
b. Check whether the bandwidth on the NNI side is sufficient for transmitting the TDM
service. For example, if n timeslots have been configured for the TDM service,
calculate the bandwidth required by one TDM service using the following formula:
TDM service bandwidth = n x 8 x 8000/8 + Length of the Ethernet packet header.
4.8 Commissioning MP Interfaces

This section describes how to commission MP interfaces.
Prerequisites
properly, and the E1 cables on the AC sides of the PPP link are correctly connected.
Context
Figure 4-6 Typical networking diagram for MP interface commissioning

Legacy 2G
BTS
BSC/RNC
Voice and Data

Over TDM CX600B
n * E1
n * E1
ATNA
Data
Over ML-PPP/ATM
3G BTS CBSC
EVDO-R0/REV
A/REV B

Equipment
Procedure
Step 1 Create a PPP serial interface and specify the protocol type of the interface as PPP. If necessary,
specify a CRC mode for the PPP link. The following uses serial interface 0/2/0:1 and mp-group
0/2/1 to describe how to commission MP interfaces. The default CRC32 mode is used for the
interfaces.
Step 2 Create an MP interface and configure the interface attributes, such as the long and short serial
numbers and fragment size. In this example, the default values are used.
Step 3 Create an MP group and add the PPP link to the MP group.
For the detailed procedure, see the guides to configure PPP and MP interfaces for ATN devices.
Then run the display this interface command on the ATN device to view the configurations of
the serial interface.
[HUAWEI-Serial0/2/0:1] display this interface
#
link-protocol ppp
ppp mp Mp-group 0/2/1
#
return
On the ATN device, run the display this command to the view the configurations of the MP
interface.
[HUAWEI-Mp-group0/2/1] display this
[PUB-910-Mp-group0/2/1]display this
interface Mp-group0/2/1
ip address 10.1.2.1 255.255.255.0
mpls
mpls ldp
#
return
Step 4 On the CX600, use the same way to configure the same number of timeslots for the E1 link and
add the timeslots to an MP group. In addition, advertise the IP address of the MP group to the
OSPF routing table. After that, the LCP state of the PPP link is opened and the MP state is open
as negotiated by the device. If MPLS is also configured, the MPLS state will be also opened.
When the MP interface is used as a network interface, the service is forwarded correctly and no
packet is lost.
[HUAWEI-Mp-group0/2/1] display this interface
Mp-group0/2/1 current state : UP
Description:HUAWEI, Mp-group0/2/1 Interface
LCP opened, MP opened, IPCP opened, MPLSCP opened
Physical is MP, baudrate is 1984000 bps
Traffic statistics:
Last 300 seconds input rate 440 bits/sec, 0 packets/sec
Last 300 seconds output rate 608 bits/sec, 0 packets/sec
Input: 727 packets, 93487 bytes
0 errors
Output: 937 packets, 131128 bytes

Equipment

----End

The PPP protocol is down.
1. Cause 1: The physical state of the interface is down.
Handling procedure:
a. In the interface view, run the display this interface command to check the physical
state of the serial interface. If the physical state is displayed as Administratively
DOWN, then the interface has been shut down manually. To turn on the interface, run
the undo shut command. If the physical state is displayed as "DOWN", see the
procedure for handling the fault of the E1 interface being down.
Serial0/2/0:1 current state : DOWN
b. On the ATN device, run the display controller e1 command to check whether the
physical state of the E1 interface corresponding to the PPP interface is down. If it is
down, see the procedure for handling the issue with the E1 interface being down.
2. Cause 2: Key parameters are inconsistent for the ATN device and CX600.
Handling procedure:
state of the serial interface.
Serial0/2/1:0 current state : DOWN
Line protocol current state : DOWN
Description:HUAWEI, Quidway Series, Serial0/2/1:0 Interface
Route Port,The Maximum Transmit Unit is 2000, Hold timer is 10
(sec)
Derived from E1 0/2/1, Unframed mode, baudrate is 2048000 bps
Internet protocol processing : disabled
LCP initial
CRC: CRC-32
b. If the VC is down, check whether the VC ID, VC type, and control word of the ATN
device are consistent with those of the CX600. If they are inconsistent, correct the
configurations to make them consistent. Note that the VC ID and control word can be
manually specified but the VC type is determined by the sub-interface type (P2P or
P2MP) and the connection type (PVC or PVP).
c. If they are the same but the VC is down, handle the fault by referring to the MPLS
3. Cause 3: A loopback has been performed for the interface.
Handling procedure:
state of the serial interface.
Serial0/2/0:1 current state : UP
Line protocol current state : DOWN
Description:HUAWEI, Quidway Series, Serial0/2/0:1 Interface
Route Port,The Maximum Transmit Unit is 2000, Hold timer is 10
(sec)
Derived from E1 0/2/0, Timeslot(s) Used: 1-31, baudrate is 1984000

Equipment
bps
Internet protocol processing : disabled
Link layer protocol is PPP, loopback is detected
b. Check whether an E1 cable loopback is performed. If this is the case, release the
loopback and ensure that the physical cable is correctly connected.
c. Check whether a loopback has been performed for the E1 interface. If there is a
loopback, release it.
The physical state or the protocol state of the MP group is down.
Handling procedure:
1. In the system view, run the display ppp mp command to check the protocol state of the
member links in the MP group.
[HUAWEI] display ppp mp interface Mp-group 0/2/1
Mp-group is Mp-group0/2/1
===========Sublinks status begin======
Serial0/2/0:1 physical DOWN,protocol DOWN
Serial0/2/1:0 physical DOWN,protocol DOWN
===========Sublinks status end========
no bundled son channel
The IPCP state of the MP group is not opened.
Handling procedure:
1. Cause 1: The number of links of which the protocol is up is smaller than the minimum
number of activated links in the MP group.
a. In the interface view, run the display this interface command to check the protocol
state of the member links in the MP group.
[HUAWEI-Mp-group0/2/1] display this interface
Mp-group0/2/1 current state : UP
Description:HUAWEI, Mp-group0/2/1 Interface
LCP opened, MP opened
MP threshold-least is 6, MP binding is 5
Physical is MP, baudrate is 7680000 bps
According to the text in bold displayed in the command output, the minimum number
of activated links is 6 but the total number of activated links is 5. Therefore, the IPCP
state of the MP group is not opened.
b. Select the member links and activate them to make the protocol state of the links up.
By doing so, you can ensure that the number of links of which the protocol state is up
is larger than or equal to the minimum number of activated links in the MP group.
2. Cause 2: The IP address of the MP group is incorrect.
a. In the interface view, run the display this or display this interface command to check
the IP address of the MP group.
l The IP address is not configured for either or both of the ATN device and CX600.
l The same IP address is configured for the ATN device and CX600.
l The IP address configured for the CX600 is in the same network segment as an IP
address of ATN device.

Equipment
3. Cause 3: One MP group on the ATN device is connected to multiple MP groups on the
CX600. In other words, the member links in the local MP group are bound to multiple MP
groups on the remote end.
a. In the system view, run the display ppp mp command to check the MP binding
configuration.
[HUAWEI] display ppp mp interface Mp-group 0/2/1
Mp-group is Mp-group0/2/1
===========Sublinks status begin======
Serial0/2/1:1 physical UP,protocol UP
===========Sublinks status end========
Bundle Multilink, 6 member, slot 0, Master link is Mp-group0/2/1
The bundled son channels are:
Serial0/2/1:1
Serial0/2/2:2
Serial0/2/3:2
Serial0/2/4:1
Serial0/2/5:1
Serial0/2/6:3
b. Bind all member links to the one MP group on the CX600 or remove some member
links from the MP group on the ATN device, and ensure that the remaining member
links are bound to the same MP group on the CX600.

Equipment
Commissioning Guide 5 Commissioning Services and Protocols
5 Commissioning Services and Protocols
About This Chapter
This chapter describes how to commission services and protocols, specifically, routing protocols,
tunnel services, VPN services, and BFD functions used when the ATN is connected to other
transport devices.
Service and Protocol Commissioning
Figure 5-1 Flowchart for commissioning services and protocols

Commissioning IGPStatic
RouteOSPFISIS
Commissioning IBGP
Commissioning MPLS
LDPMPLS TE
Commissioning VPN
L3VPNL2VPN
Commissioning BFD
5.1 Commissioning Static Routes

This section describes how to commission static routes.
5.2 Commissioning OSPF Routes
This section describes how to commission OSPF routes.
5.3 Commissioning IS-IS Routes

Equipment
This section describes how to commission IS-IS routes.
5.4 Commissioning IBGP Routes

This section describes how to commission IBGP routes.
5.5 Commissioning MPLS LDP

This section describes how to commission MPLS LDP.
5.6 Commissioning MPLS TE

This section describes how to commission MPLS TE.
5.7 Commissioning BGP/MPLS IP VPN

This section describes how to commission BGP/MPLS IP VPN.
5.8 Commissioning VPWS

This section describes how to commission VPWS.
5.9 Commissioning VPLS

This section describes how to commission VPLS.
5.10 Commissioning BFD

This section describes how to commission BFD.
5.11 Commissioning a DCN

To commission a DCN, users must configure routing protocols based on the network plan. This
section describes how to commission a DCN.
5.12 Commissioning Clocks

This section describes how to commission clocks.

Equipment
5.1 Commissioning Static Routes

This section describes how to commission static routes.
Prerequisite
l The hardware has been checked. For more information, see 3 Checking the Hardware.
l The link layer has been commissioned. For more information, see 4 Commissioning the
Link Layer.
Context
On the network shown in Figure 5-2, static routes are configured on the network to ensure
successful communication between the commissioning device and the network connected to
CX600 B.
Figure 5-2 Typical networking for commissioning static routes

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
Console GE0/2/0 network
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
Procedure
Step 1 Run the display ip routing-table command on the commissioning device to check whether the
routing table contains static routes.
<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 6 Routes : 6
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
192.168.1.0/24 Direct 0 0 D 192.168.1.1
GigabitEthernet0/2/4
192.167.1.0/24 Static 60 0 RD 192.168.1.2 GigabitEthernet0/2/0
The boldfaced items in the command output show the information about the static route between
the commissioning device and the network connected to CX600 B.
Step 2 Run the display ip routing-table protocol command on the commissioning device to check
route information about the specified routing protocol.
<HUAWEI> display ip routing-table protocol static
------------------------------------------------------------------------------
Public routing table : Static
Destinations : 1 Routes : 1 Configured Routes : 1
Static routing table status : <Active>

Equipment
192.167.1.0/24 Static 60 0 RD 192.168.1.2
Static routing table status : <Inactive>
The boldfaced items in the command output show the information about the activated static
routes. Then check the number of activated static routes, destination network addresses,
preferences, costs, next-hop addresses, and outbound interfaces.
Step 3 Run the ping command on the commissioning device to test the availability of the static routes.
<HUAWEI> ping 192.167.1.10
--- 192.167.1.10 ping statistics ---

0.00% packet loss
The preceding command output shows that the commissioning device has a reachable IS-IS
route to the CX600 B.
----End
Troubleshooting
If static routes are correctly configured but the commissioning device fails to receive some or
all routes, complete the following:
1. Check that static route parameters are correctly configured.

Run the display current-configuration | include route-static command to check whether
static route parameters are correct and destination addresses, outbound interfaces, and next
hops of IPv4 static routes are configured.
2. Check that the precedence of static routes is correctly configured.
Run the display ip routing-table command to check the precedence of static routes in the
IPv4 routing table.
The precedence of static routes is 60 by default, being lower than OSPF routes (10) and
IS-IS routes (15). Therefore, if OSPF or IS-IS is also configured, to make static routes take
effect, run the ip route-static default-preference preference command to set the default
precedence of static routes to be higher than that of OSPF routes or IS-IS routes before
configuring static routes. The smaller the preference value, the higher the preference.
3. If the fault persists, collect the following information and contact Huawei technical support
personnel.
l Configuration files, log files, and alarm files of the devices

Equipment
5.2 Commissioning OSPF Routes

This section describes how to commission OSPF routes.
Prerequisite
Link Layer.
Context
On the network shown in Figure 5-3, OSPF is configured on the network to ensure successful
communication between the commissioning device and the network connected to CX600 B.
Figure 5-3 Typical networking for commissioning OSPF routes

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
Procedure
Step 1 Run the display ospf peer command on the commissioning device to view its OSPF neighbor
information.
<HUAWEI> display ospf peer
OSPF Process 1 with Router ID 1.1.1.1
Neighbors
Area 0.0.0.0 interface 192.168.1.1(GigabitEthernet0/2/0)'s neighbors
Router ID: 2.2.2.2 Address: 192.168.1.2
State: Full Mode:Nbr is Slave Priority: 1
DR: 192.168.1.1 BDR: 192.168.1.2 MTU: 0
Dead timer due in 35 sec
Retrans timer interval: 5
Neighbor is up for 00:00:05
Authentication Sequence: [ 0 ]
The boldfaced items in the command output show the OSPF neighbor information. Then check
the number of neighbors, whether or not the neighbor relationships are in the Full state (indicating
that the neighbors have finished LSDB synchronization and established the Full adjacency) and
whether or not the neighbors can remain in the Up state for a long time. If a neighbor stays in
the Up state for a short period of time, the OSPF neighbor relationship has been recently
interrupted. Pay attention to such a symptom.
Step 2 Run the display ospf routing command on the commissioning device to view information about
the OSPF routing table.
Intra-area OSPF routes:
<HUAWEI> display ospf routing

Equipment
Routing Tables
Routing for Network

Destination Cost Type NextHop AdvRouter Area
192.168.1.0/24 1 transit 192.168.1.1 1.1.1.1 0.0.0.0
2.2.2.2/32 1 Stub 192.168.1.2 2.2.2.2 0.0.0.0
192.167.1.0/24 2 Stub 192.168.1.2 2.2.2.2 0.0.0.0
Total Nets: 3
Intra Area: 3 Inter Area: 0 ASE: 0 NSSA: 0
In the command output, check the destination network addresses, route costs, destination
network types, next-hop addresses, routers advertising the routes, AS numbers, and total number
of networks of each type. The OSPF routes in the preceding command output are intra-area
routes.
Inter-area OSPF routes:

<HUAWEI> display ospf routing
Routing Tables
Routing for Network

Destination Cost Type NextHop AdvRouter Area
192.168.1.0/24 1 transit 192.168.1.1 1.1.1.1 0.0.0.0
2.2.2.2/32 1 Stub 192.168.1.2 2.2.2.2 0.0.0.0
192.167.1.0/24 2 Inter-area 192.168.1.2 2.2.2.2 0.0.0.0
Routing for ASEs

Destination Cost Type Tag NextHop AdvRouter
190.120.0.0/16 3 Type1 1 192.168.1.2 3.3.3.3
200.0.0.0/24 3 Type1 1 192.168.1.2 3.3.3.3
Total Nets: 5
Intra Area: 2 Inter Area: 1 ASE: 2 NSSA: 0
If the commissioning device has learned routes from other areas using OSPF, the routing table
will contain them. The boldfaced items in the command output show that there are two intra-
area routes, one inter-area route, and two AS external routes.
Step 3 Run the display ospf interface command on the commissioning device to view its OSPF
interface information.
<HUAWEI> display ospf interface
Interfaces
Area: 0.0.0.0 (MPLS TE not enabled)

IP Address Type State Cost Pri DR BDR
1.1.1.1 P2P P-2-P 0 1 0.0.0.0 0.0.0.0
192.168.1.1 Broadcast DR 1 1 192.168.1.1 192.168.1.2
The boldfaced items in the command output show the OSPF interface information. Check that
the type, state, and cost of the OSPF-enabled interface are correct.
Step 4 Run the display current-configuration command on the commissioning device to check the
configurations that have taken effect.
<HUAWEI> display current-configuration
#
ospf 1 vpn-instance comm_signal
default-route-advertise always cost 1024 type 2
import-route direct
import-route static
route-tag 100
area 0.0.0.0
network 192.168.1.0

Equipment
0.0.0.255
network 1.1.1.1 0.0.0.0
#
The boldfaced items in the command output show the configurations that have taken effect.
Check that the OSPF VPN is correctly configured by checking the configurations of the OSPF
process ID, tag value, and default route delivery.
Step 5 Run the display ospf error command on the commissioning device to view OSPF errors.
<HUAWEI> display ospf error
OSPF error statistics
General packet errors:

0 : IP: received my own packet 0 : Bad packet
0 : Bad version 0 : Bad checksum
0 : Bad area id 0 : Drop on unnumbered interface
0 : Bad virtual link 0 : Bad authentication type
0 : Bad authentication key 0 : Packet too small
0 : Packet size > ip length 0 : Transmit error
0 : Interface down 0 : Unknown neighbor
HELLO packet errors:

0 : Netmask mismatch 0 : Hello timer mismatch
0 : Dead timer mismatch 0 : Extern option mismatch
0 : Router id confusion 0 : Virtual neighbor unknown
0 : NBMA neighbor unknown 0 : Invalid Source Address
DD packet errors:
0 : Neighbor state low 0 : Router id confusion
0 : Extern option mismatch 0 : Unknown LSA type
0 : MTU option mismatch
LS ACK packet errors:

0 : Neighbor state low 0 : Unknown LSA type
LS REQ packet errors:

0 : Neighbor state low 0 : Empty request
0 : Bad request
LS UPD packet errors:

0 : Neighbor state low 0 : Newer self-generate LSA
0 : LSA checksum bad 0 : Received less recent LSA
0 : Unknown LSA type
Opaque errors:
0 : 9-out of flooding scope 0 : 10-out of flooding scope
0 : 11-out of flooding scope 0 Unkown TLV
type
Retransmission for packet over Limitation errors:

0 : Number for DD Packet 0 : Number for Update Packet
0 : Number for Request Packet
Receive Grace LSA errors:

0 : Number of invalid LSAs 0 : Number of policy failed LSAs
0 : Number of wrong period LSAs
Configuration errors:
0 : Tunnel cost mistake
To locate OSPF faults, you can run this command to view OSPF error information. OSPF error
information is a basis for OSPF fault diagnosis.
Step 6 Run the ping command on the commissioning device to test the availability of OSPF routes.
<HUAWEI> ping 192.167.1.10

Equipment

--- 192.167.1.10 ping statistics ---

0.00% packet loss
The preceding command output shows that the commissioning device has a reachable OSPF
route to the network connected to CX600 B.
----End
Troubleshooting
If the OSPF neighbor relationship is Down after OSPF is configured, complete the following:
1. Check logs to find the cause of the Down OSPF neighbor relationship.
Run the display logbuffer command to view the following log information:
NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=
[USHORT], NeighborRouterId=[IPADDR], NeighborAreaId=[ULONG],
NeighborInterface=[STRING],NeighborDownImmediate reason=[STRING],
NeighborDownPrimeReason=[STRING], NeighborChangeTime=[STRING])
Check the NeighborDownImmediate reason field which records the cause of the Down
OSPF neighbor relationship. Possible causes are as follows:
l Neighbor Down Due to Inactivity
It indicates that the local end does not receive any Hello packet from its neighbor within
the deadtime, and hence the OSPF neighbor relationship becomes Down. In this case,
go to Step 2.
l Neighbor Down Due to Kill Neighbor
It indicates that the interface or BFD session is in the Down state, or the reset ospf
process command is run and hence the OSPF neighbor relationship becomes Down. In
this case, check the NeighborDownPrimeReason field to find the specific cause of the
fault.
If the NeighborDownPrimeReason field displays Physical Interface State
Change, the interface status has changed. In this case, run the display interface
[ interface-type [ interface-number ] ] command to check the interface status, and
then rectify the interface fault.
If the NeighborDownPrimeReason field displays OSPF Process Reset, the reset
ospf process command has been executed. Whether or not this command has been
run can be ensured by checking the operation records or log information.
If the NeighborDownPrimeReason field displays BFD Session Down, the BFD
session status has become Down. In this case, rectify the BFD fault.
l Neighbor Down Due to 1-Wayhello Received or Neighbor Down Due to SequenceNum
Mismatch
It indicates that the OSPF status on the remote end becomes Down before the remote
end sends a 1-Way Hello packet to the local end, causing the OSPF status on the local
end to become Down as well. In this case, rectify the fault on the remote end.

Equipment
l In other cases, go to Step 9.

2. Check that the link between the two ends works normally.
Check that the link between the two ends is working normally, including the transmission
devices. If the link works properly, go to Step 3.
3. Check that the CPU usage is within the normal range.
Check whether or not the CPU usage on the MPU or LPU of the faulty device is too high.
If the CPU usage is too high, OSPF fails to receive and send protocol packets, causing the
neighbor relationship to flap. In this case, rectify the high CPU usage fault. If the CPU
usage is within the normal range, go to Step 4.
4. Check that the interface status is Up.
Run the display interface [ interface-type [ interface-number ] ] command to check the
physical status of the interface. If the physical status of the interface is Down, rectify the
interface fault.
If the physical status of the interface is Up, run the display ospf interface command to
check that the OSPF status of the interface is Up.
Interfaces

IP Address Type State Cost Pri DR
BDR
192.168.1.1 Broadcast DR 1 1 192.168.1.1
0.0.0.0
l If the OSPF status of the interface is Down, run the display ospf cumulative command
to check whether or not the number of interfaces enabled with OSPF in the OSPF process
exceeds the limit. If so, reduce the number of interfaces enabled with OSPF.
<HUAWEI> display ospf cumulative
Cumulations
IO Statistics
Type Input Output
Hello 28310 134625
DB Description 32 25
Link-State Req 17 9
Link-State Update 1051 657
Link-State Ack 606 982
ASE: (Disabled)
LSAs originated by this router
Router: 1
Network: 11
Sum-Net: 0
Sum-Asbr: 0
External: 0
NSSA: 0
Opq-Link: 0
Opq-Area: 20
Opq-As: 0
LSAs Originated: 32 LSAs Received: 1448
Routing Table:
Intra Area: 11 Inter Area: 0 ASE: 0
Up Interface Cumulate: 6
Neighbor Cumulate:
=======================================================
Neighbor cumulative data. (Process 88)
-------------------------------------------------------
Down: 0 Init: 0 Attempt: 0 2-Way: 0
Exstart: 0 Exchange: 0 Loading: 0 Full: 1

Equipment
Retransmit Count: 0
Neighbor cumulative data. (Total)
-------------------------------------------------------
Down: 0 Init: 0 Attempt: 0 2-Way: 0
Exstart: 0 Exchange: 0 Loading: 0 Full: 1
Retransmit Count: 0
l If the OSPF status of the interface is normal (for example, DR, BDR, DR Other, or P2P),
go to Step 5.
5. Check that the IP addresses of the two ends are on the same network segment.
l If the IP addresses of the two ends are on different network segments, modify the IP
address of one end.
l If the IP addresses of the two ends are on the same network segment, go to Step 6.
6. Check that MTUs of the interfaces on both ends are consistent.
If ospf mtu-enable is enabled on the interfaces, the interface MTUs must be consistent.
Otherwise, OSPF neighbors cannot negotiate with each other successfully.
l If MTUs of the interfaces on both ends are inconsistent, run the mtu mtu command in
the interface view to change MTUs of the interfaces to be consistent on both ends.
l If the MTUs of the interfaces on both ends are consistent, go to Step 7.
7. Check that there is at least one interface whose priority is not 0.
On the broadcast and NBMA networks, there should be at least one interface whose priority
is not 0, which ensures that a DR is elected correctly. Otherwise, the state of the OSPF
neighbor relationship can only reach 2-Way.
Run the display ospf interface command to view the interface priority.
Interfaces
BDR
192.168.1.1 Broadcast DR 1 1 192.168.1.1
0.0.0.0
8. Check that OSPF configurations on both ends are correct.

a. Check whether the OSPF router IDs of the two ends conflict.
<HUAWEI> display ospf brief
OSPF Protocol Information
If OSPF router IDs of the two ends conflict, correct the configurations. Otherwise,
proceed with the following check.
b. Check whether the OSPF area configurations on both ends are consistent.
Interfaces
BDR
192.168.1.1 Broadcast DR 1 1 192.168.1.1
0.0.0.0
c. Check whether other OSPF configurations on both ends are consistent.

Run the display ospf error command every 30s for 3 times.
<HUAWEI> display ospf error

Equipment
OSPF error statistics

General packet errors:
0 : IP: received my own packet 0 : Bad packet
0 : Bad version 0 : Bad checksum
0 : Bad area id 0 : Drop on unnumbered
interface
0 : Bad virtual link 0 : Bad authentication type
0 : Bad authentication key 0 : Packet too small
0 : Packet size > ip length 0 : Transmit error
0 : Interface down 0 : Unknown neighbor
HELLO packet errors:
0 : Netmask mismatch 0 : Hello timer mismatch
0 : Dead timer mismatch 0 : Extern option mismatch
0 : Router id confusion 0 : Virtual neighbor unknown
0 : NBMA neighbor unknown 0 : Invalid Source Address
l Check the Bad authentication type field. If the value of this field continually
increases, the OSPF authentication types of the two ends that establish the neighbor
relationship are different. In this case, you need to set the same authentication type
for both ends.
l Check the Hello timer mismatch field. If the value of this field continually
increases, the values of the Hello timers on the two ends that establish the neighbor
relationship are different. In this case, you need to check the interface
configurations of the two ends and set the same value for their Hello timers.
l Check the Dead timer mismatch field. If the value of this field continually
increases, the dead timers on the two ends that establish the neighbor relationship
are different. In this case, you need to check the interface configurations of the two
ends and set the same value for their dead timers.
l Check the Extern option mismatch field. If the value of this field continually
increases, the area types of the two ends that establish the neighbor relationship
are different (the area type of one device is common area, and that of the other
device is stub area or NSSA). In this case, you need to set the same area type for
both ends.
If the fault persists, proceed to Step 9.
5.3 Commissioning IS-IS Routes

This section describes how to commission IS-IS routes.
Prerequisites
Link Layer.
Context
On the network shown in Figure 5-4, IS-IS is configured on the network to ensure successful

Equipment
Figure 5-4 Typical networking for commissioning IS-IS routes

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
Procedure
Step 1 Run the display isis peer command on the commissioning device to view its IS-IS neighbor
information.
<HUAWEI> display isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI
-------------------------------------------------------------------------------
0000.0001.0000 GE0/2/0 0001.0000.0100.01 Up 25s L1(L1L2)
64
Total Peer(s): 1
The boldfaced items in the command output show IS-IS neighbor information. Check the number
of IS-IS neighbors, whether or not the neighboring interface is in the Up state, and the IS-IS
type.
Step 2 Run the display isis interface command on the commissioning device to view its IS-IS interface
information.
<HUAWEI> display isis interface
Interface information for ISIS(2)
---------------------------------
Interface Id IPV4.State MTU Type DIS
GE0/2/0 001 Up 1497 L1/L2 No/No
The boldfaced items in the command output show the IS-IS interface information. Check that
OSPF-enabled interfaces are correctly configured, the number of OSPF-enabled interfaces is
correct, and that the IPv4.State of the interfaces is Up.
Step 3 Run the display isis route command on the commissioning device to view IS-IS routing
information.
<HUAWEI> display isis route
Route information for ISIS(1)
-------------------------------
ISIS(1) Level-2 Forwarding Table
----------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags
----------------------------------------------------------------------------
192.167.1.0/24 20 NULL GE0/2/0 192.168.1.2 A/-/-/-
192.168.1.0/24 10 NULL GE0/2/0 Direct D/-/L/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set
Focus on checking that the destination IP addresses, internal costs, outbound interfaces, next-
hop addresses, and routing information flags are correct.
Step 4 Run the display current-configuration command on the commissioning device to check the
configurations that have taken effect.
#
isis 1

Equipment
graceful-restart
cost-style wide
timer lsp-generation 1 level-2
flash-flood level-2
network-entity 0000.0000.0001.01
is-name ngn-r2-b-sxxa-2
import-route isis level-2 into level-1 //Route leaking is required only on the BR
but not the AR.
nexthop 192.168.1.2 weight 100 //An IS-IS weight is set correctly. (The next hop
indicates the peer IP address.)
timer spf 1 50 50
traffic-eng level-2 //Enable different levels of TE for different IS-IS
processes. On the BR with TE not deployed, this command is not required.
log-peer-change
#
There is a description following each field in the command output to emphasize the point that
needs to be paid attention to.
Step 5 Run the ping command on the commissioning device to test the availability of IS-IS routes.
<HUAWEI> ping 192.167.1.10
--- 192.167.1.10 ping statistics ---

0.00% packet loss
The preceding command output shows that the commissioning device has a reachable IS-IS
route to the network connected to CX600 B.
----End
Troubleshooting
If the IS-IS neighbor relationship cannot be established after IS-IS is configured, complete the
following:
1. Check that IS-IS can receive and send Hello packets properly.
Run the display isis statistics packet [ interface interface-type interface-number ]
command to check that IS-IS can normally receive and send Hello packets.
NOTE
The default interval at which IS-IS sends Hello packets is 10s. Therefore, run this command every
10s to check whether or not the packet statistics increase.
On a broadcast interface, IS-IS Hello packets have IS-IS levels, and therefore you can view Hello
packet statistics based on the levels of established neighbor relationships. On a P2P interface, IS-IS
Hello packets have no IS-IS levels and are recorded as L2 IIH packets.
l If the number of received Hello packets does not increase for a certain period, check
whether or not packet loss has occurred at the lower layer or at the link between the two
ends.
l If the number of received Hello packets increases gradually, perform the following
operations based on interface types:

Equipment
If the interfaces on both ends are trunk interfaces, check that the numbers of the
trunk member interfaces in the Up state are the same on both ends.
If the interfaces on both ends are not trunk interfaces, go to next step.
2. Check that the interface status is Up.
Run the display ip interface [ interface-type interface-number ] command to check the
status of a specified interface.
l If the interface status is not Up, rectify the interface fault. For detailed troubleshooting
procedures, see "Interface & Physical Connection Troubleshooting" and "Layer 2
Network Troubleshooting."
l If the interface status is Up, go to next step.
3. Check the status of IS-IS interfaces.
Run the display isis interface command to check the status of the interfaces enabled with
IS-IS.
l If the interface status is Mtu:Dn/Lnk:Up/IP:Up, run the display current-
configuration interface interface-type [ interface-number ] command to check the
MTUs of the interfaces. Run the display current-configuration configuration isis
command to check the LSP length configured in the IS-IS process. On a P2P interface,
the LSP length should not be greater than the MTU. On a broadcast interface, the value
obtained by subtracting the LSP length from the MTU should be greater than or equal
to 3. If these conditions are not met, change the MTU of the interface or the LSP length.
l If the interface status is Down, run the display current-configuration configuration
isis command to check the configuration of the IS-IS process. Check that the NET is
configured in the IS-IS process. If not, configure the NET in the IS-IS process.
l If the interface status is Mtu:Up/Lnk:Dn/IP:Dn, check that IS-IS interfaces are
configured with IP addresses.
l If the interface status is Up, go to next step.
4. Check that the IP addresses of the two ends are on the same network segment.
l If the IP addresses of the two ends are on different network segments, modify the IP
address of one end.
l If the IP addresses of the two ends are on the same network segment, go to next step.
5. Check that both ends are configured with different system IDs.
Run the display current-configuration configuration isis command to check whether or
not the system IDs of the two ends are the same.
l If the system IDs of the two ends are the same, set different system IDs for each end.
l If the system IDs of the two ends are different, go to next step.
6. Check that the IS-IS levels of the two ends are consistent.
Run the display current-configuration configuration isis | include is-level command to
check the levels of the IS-IS processes on both ends. Then, run the display current-
configuration interface interface-type interface-number | include isis circuit-level
command to check whether or not the IS-IS levels of the interfaces at both ends are
consistent. The IS-IS neighbor relationship can only be established when the IS-IS levels
of the two interfaces are consistent.

Equipment
l If the IS-IS levels of the interfaces at both ends are inconsistent, run the is-level
command in the IS-IS view to change the IS-IS level of one end, or run the isis circuit-
level command in the interface view to change the IS-IS level of the interface.
l If the IS-IS levels of the interfaces at both ends are consistent, go to next step.
7. Check that the area addresses of the two ends are the same.
When the area addresses of the two ends are different, the alarm isisAreaMismatch is
generated.
NOTE
If the two ends establish a Level-1 neighbor relationship, ensure that they are both in the same area.
An IS-IS process can be configured with a maximum of three area addresses. As long as one of the
area addresses of the local IS-IS process is the same as one of the area addresses of the remote IS-IS
process, the Level-1 neighbor relationship can be established.
When an IS-IS Level-2 neighbor relationship is established between two ends, you do not need to
determine whether or not the area addresses of the two ends are the same.
l If the area addresses of the two ends are different, run the network-entity command in
the IS-IS view to set the same area address for both ends.
l If the area addresses of the two ends are the same, go to next step.
8. Check that the authentication configurations on the two ends are the same.
If the authentication modes configured on the two ends are different, the alarm
isisAuthenticationTypeFailure or isisAuthenticationFailure is generated.
Run the display current-configuration interface interface-type interface-number |
include isis authentication-mode command to check IS-IS authentication configurations
on the interfaces of the two ends.
l If the authentication modes configured on both are different, run the isis authentication-
mode command in the IS-IS interface view on both ends to set the same authentication
mode.
l If the authentication password configured on both are different, run the isis
authentication-mode command in the IS-IS interface view on both ends to set the same
authentication password.
l If the authentication modes configured on both ends are the same, go to next step.
9. Collect the following information and contact Huawei technical support personnel.
5.4 Commissioning IBGP Routes

This section describes how to commission IBGP routes.
Prerequisites
Link Layer.

Equipment
Context
On the network shown in Figure 5-5, IBGP is configured on the network to ensure successful
Figure 5-5 Typical networking for commissioning IBGP routes

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
AS100
Procedure
Step 1 Run the display bgp peer command to view IBGP peer information.
<HUAWEI> display bgp peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State
PrefRcv
2.2.2.2 4 100 274 7 14 03:07:01 Established 3
The boldfaced items in the command output show the IBGP peer information. Check that the
IBGP peer address and AS number are correct. Normally, the IBGP peer relationship should be
in the Established state.
Step 2 Run the display bgp routing-table command on the commissioning device to view IBGP
routing information.
l View all IBGP routing information:
<HUAWEI> display bgp routing-table
BGP Local router ID is 1.1.1.1
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S -
Stale
Origin : i - IGP, e - EGP, ? - incomplete
.............................................................
Total Number of Routes: 1
Network NextHop MED LocPrf PrefVal Path/
Ogn
*> 2.2.2.2/32 0.0.0.0 1 0 ?
*> 192.168.1.0/24 0.0.0.0 0 0 ?
* i 2.2.2.2 0 0 i
*> 192.168.1.1/32 0.0.0.0 0 0 ?
*> 192.167.1.0/24 0.0.0.0 0 0 ?
* i 2.2.2.2 0 100 0 i
*> 1.1.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
Check that the network addresses, next-hop addresses, metrics, and local preferences of BGP
routes are correct. The boldfaced items in the command output show the default route and
specific routes received from AS 300, summarized routes received from AS 400, and that

Equipment
the local preference of the routes received from AS 300 and AS 400 is set to 100 by the
configured routing policy.
l View detailed information about the specified IBGP routes:
<HUAWEI> display bgp routing-table 192.167.1.0
Paths: 2 available, 1 best, 1 select
BGP routing table entry information of 192.167.1.0/24:
Imported route.
From: 0.0.0.0 (0.0.0.0)
Route Duration: 01h22m50s
Direct Out-interface: GigabitEthernet0/2/0
Original nexthop:
192.168.1.2
Qos information : 0x0
Community:no-export
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, pre 255
Advertised to such 1 peers:
2.2.2.2
From: 2.2.2.2 (2.2.2.2)
Relay IP Nexthop: 192.168.1.2
Relay IP Out-Interface: GigabitEthernet0/2/0
Original nexthop: 2.2.2.2
pre
255, not preferred for route type
Not advertised to any peer yet
The boldfaced items in the command output show the detailed information about the specified
IBGP routes. Check that the local router IDs, AS numbers, sources of IBGP routes, outbound
interfaces, and next-hop addresses are correct. The IBGP routes in the command output have
community attributes, which prevents ATN A from advertising the routes received from
CX600 B to other ASs.
l View information about the routes with community attributes:
<HUAWEI> display bgp routing-table community
h - history, i - internal, s - suppressed, S - Stale

Network NextHop MED LocPrf PrefVal Community
*>i 192.167.1.0 2.2.2.2 0 100 0 no-export
l Commissioning the RR of IBGP routes:

CX600 B is the RR of cluster 1 and ATN A is the client of CX600 B. 192.167.1.0/24 is the
network address of non-clients.
<HUAWEI> display bgp routing-table 192.167.1.0
Imported route.
From: 0.0.0.0 (0.0.0.02)
Original nexthop:
192.168.1.2

Equipment
Community:no-export
best, select, pre 255
2.2.2.2
From: 2.2.2.2 (2.2.2.2)
pre
255, not preferred for route type
Originator: 4.4.4.4
Cluster list: 0.0.0.1
The boldfaced items in the command output show that ATN A has learned routes of the
network segment 192.167.1.0 advertised by CX600 B, and shows the Originator and
Cluster_ID of the learned routes.
Step 3 Run the display bgp peer ipv4-address verbose command to view the configurations of GR
functions for IBGP.
<HUAWEI> display bgp peer 2.2.2.2 verbose
BGP Peer is 2.2.2.2, remote AS 100
Type: IBGP link
BGP version 4, Remote router ID 2.2.2.2
Update-group ID : 1
BGP current state: Established, Up for 00h49m35s
BGP current event: KATimerExpired
BGP last state: OpenConfirm
BGP Peer Up count: 1
Received total routes: 1
Received active routes total: 1
Advertised total routes: 2
Port: Local - 179 Remote - 52876
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Received : Active Hold Time: 180 sec
Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec
Peer optional capabilities:
Peer supports bgp multi-protocol extension
Peer supports bgp route refresh capability
Peer supports bgp 4-byte-as capability
Graceful Restart Capability: advertised
Address family IPv4 Unicast: advertised and received
Received: Total 59 messages
Update messages 0
Open messages 2
KeepAlive messages 57
Notification messages 0
Refresh messages 0
Sent: Total 79 messages
Update messages 5
Open messages 2
KeepAlive messages 71
Notification messages 1
Refresh messages 0
Authentication type configured: None
Last keepalive received: 2010-02-20 13:54:58
Minimum route advertisement interval is 30 seconds
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
Connect-interface has been configured

Equipment
Peer Preferred Value: 0

Routing policy configured:
No routing policy is configured
The boldfaced items in the command output show that the number of valid hops is 1, the BGP
peer relationship is in the Established state, and the GR function is enabled for IBGP.
Step 4 Run the ping command on the commissioning device to test the availability of IBGP routes.

0.00% packet loss
2.2.2.2 is the loopback address of CX600 B.
----End
Troubleshooting
If the BGP peer relationship cannot be established on a BGP-deployed network, complete the
following:
1. Run the ping command to check that BGP peers can ping each other successfully.
l If they can ping each other successfully, it indicates that there are available routes
between the BGP peers and that link transmission is normal. Proceed to Step 2.
NOTE
Run the ping -a source-ip-address -s packetsize host command to detect the connectivity of each
end. Because the source address is specified in this command, you can check whether or not
routes between the two ends are accessible. By specifying the size of a Ping packet, you can also
check whether or not long Ping packets can be normally transmitted over the link.
l If the ping fails, follow the procedure described in "The Ping Operation Fails" in the
ATNMulti-service Access Equipment Troubleshooting to find whether or not the
routing tables on each end have available routes to each other.
2. Check that no ACL is configured to filter packets whose destination port is TCP port 179.
Run the display acl all command on both ends to check whether or not an ACL is configured
to filter packets whose destination port is TCP port 179.
<HUAWEI> display acl all
Total nonempty ACL number is 1
Advanced ACL 3001, 2 rules

Acl's step is 5
rule 5 deny tcp source-port eq bgp
rule 10 deny tcp destination-port eq bgp
l If an ACL is configured to filter packets whose destination port is TCP port 179, delete
the ACL configuration.

Equipment
l If no ACL is configured to filter packets whose destination port is TCP port 179, go to
Step 3.
3. Check that the peer router ID does not conflict with the local router ID.
Check information about BGP peers to ensure that their router IDs do not conflict. For
example, if the IPv4 unicast peer relationship fails to be established, you can run the display
bgp peer command to check whether or not the peer router ID conflicts with the local router
ID. Use the following command output as an example:

PrefRcv
8.9.0.8 4 100 1601 1443 0 23:21:56 Established
10000
9.10.0.10 4 200 1565 1799 0 23:15:30 Established
9999
NOTE
To check information about BGP peers in the BGP-VPNv4 address family or the BGP-VPN instance
address family, you can run the display bgp vpnv4 all peer command.
l If the peer router ID conflicts with the local router ID, run the router id command in
the BGP view to modify the router IDs to agree. Generally, a loopback interface address
is used as the local router ID.
l If the peer router ID does not conflict with the local router ID, go to Step 4.
4. Check that the peer AS number is configured correctly.
Run the display bgp peer command on each end to check that the displayed peer AS
number is the same as that of the remote end.

PrefRcv
8.9.0.8 4 100 1601 1443 0 23:21:56 Established
10000
9.10.0.10 4 200 1565 1799 0 23:15:30 Established
9999
NOTE
To check information about BGP peers in the BGP-VPNv4 address family or the BGP-VPN instance
address family, you can run the display bgp vpnv4 all peer command.
l If the peer AS number is configured incorrectly, change it to be the same as that of the
remote end.
l If the peer AS number is configured correctly, go to Step 5.
5. Check whether or not BGP configurations affect the establishment of the BGP peer
relationship.
Run the display current-configuration configuration bgp command to check BGP
configurations.
Table 5-1 describes the checklist for BGP configurations.

Equipment
Table 5-1 Checklist for BGP configurations
Item Description
peer connect-interface interface- If two ends use loopback interfaces to establish

type interface-number the BGP peer relationship, you need to run the
peer connect-interface command to specify
the associated loopback interface as the source
interface that sends BGP packets.
peer route-limit limit If the peer route-limit limit limit command is

configured, check whether or not the number of
routes sent by the peer exceeds the limit that is
specified by limit. If it is exceeded, you need to
reduce the number of routes sent from the peer,
and run the reset bgp ip-address command to
reset the BGP peer relationship and trigger the
reestablishment of the BGP peer relationship.
peer ignore If the peer ignore command is configured on

the peer, it indicates that the peer is not required
to establish the BGP peer relationship with the
local end temporarily. To establish the BGP
peer relationship between the remote peer and
local peer, run the undo peer ignore command
on the peer.
peer enable Check that the address family capabilities of the

two ends match. For example, before
establishing the BGP VPNv4 peer relationship,
you need to configure the peer enable
command in the BGP-VPNv4 address families
of the two ends. If the peer enable command is
only configured on one end, the BGP peer
relationship of the other end is displayed as No
neg.
5.5 Commissioning MPLS LDP

This section describes how to commission MPLS LDP.
Prerequisite
Link Layer.

Equipment
Context
On the network shown in Figure 5-6, MPLS LDP is configured on the network.
Figure 5-6 Typical networking for commissioning MPLS LDP

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
Procedure
Step 1 Run the display mpls ldp peer command to view LDP peer information.
<HUAWEI> display mpls ldp peer
LDP Peer Information in Public network
A '*' before a peer means the peer is being deleted.
-------------------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
-------------------------------------------------------------------------
2.2.2.2:0 2.2.2.2 Remote Peer : 2.2.2.2
-------------------------------------------------------------------------
TOTAL: 1 Peer(s) Found.
Check that the number of LDP peers is correct.

Step 2 Run the display mpls ldp session command to check information about the session between
LDP peers.
<HUAWEI> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
--------------------------------------------------------------------------
Peer-ID Status LAM SsnRole SsnAge KASent/Rcv
--------------------------------------------------------------------------
2.2.2.2:0 Operational DU Active 0000:00:22 12984/12991
--------------------------------------------------------------------------
TOTAL: 1 Session(s) Found.
The Status field in the preceding command output is commonly displayed as Operational,
indicating that an LDP session has been established. The LAM field is commonly displayed as
DU, indicating that the label distribution mode is Downstream Unsolicited. The SsnRole field
can be displayed as Passive, indicating the responder of an LDP session, or as Active, indicating
the initiator of an LDP session.
Step 3 Run the display mpls ldp interface command on the commissioning device to view information
about the interfaces enabled with MPLS LDP.
<HUAWEI> display mpls ldp interface
LDP Interface Information in Public Network
Codes:LAM(Label Advertisement Mode), IFName(Interface name)
A '*' before an interface means the entity is being deleted.
-------------------------------------------------------------------------------
IF-Name Status LAM Transport-Address Hello-Sent/Rcv
-------------------------------------------------------------------------------
GE0/2/0 Active DU 1.1.1.1 56259/0
-------------------------------------------------------------------------------

Equipment
Check whether LDP-enabled interfaces are correctly configured and the number of LDP-enabled
interfaces is correct.
Step 4 Run the display mpls ldp lsp command on the commissioning device to view information about
the outbound interfaces of LDP LSPs, next-hop addresses, number of LDP LSPs, and types of
LDP LSPs.
<HUAWEI> display mpls ldp lsp
LDP LSP Information
------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
------------------------------------------------------------------------------
3.3.3.3/32 NULL/2075 - 192.168.1.2 GE0/2/0
3.3.3.3/32 1657/2075 2.2.2.2 192.168.1.2 GE0/2/0
2.2.2.2/32 NULL/3 192.168.1.2 GE0/2/0
2.2.2.2/32 1656/3 2.2.2.2 192.168.1.2 GE0/2/0
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/2078 DS/2.2.2.2
------------------------------------------------------------------------------
TOTAL: 5 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is in GR state
A '*' before a DS means the session is in GR state
A '*' before a NextHop means the LSP is FRR LSP
Step 5 Run the display mpls lsp command on the commissioning device to view LSP information.
<HUAWEI> display mpls lsp
----------------------------------------------------------------------
LSP Information: LDP LSP
----------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
1.1.1.1/32 3/NULL -/-
2.2.2.2/32 NULL/3 -/GE0/2/0
2.2.2.2/32 1656/3 -/GE0/2/0
3.3.3.3/32 NULL/2075 -/GE0/2/0
3.3.3.3/32 1657/2075 -/GE0/2/0
Step 6 Run the display mpls lsp verbose command on the commissioning device to view detailed LSP
information.
<HUAWEI> display mpls lsp verbose
----------------------------------------------------------------------
LSP Information: LDP LSP
----------------------------------------------------------------------
No : 1
VrfIndex :
Fec : 1.1.1.1/32
Nexthop : 127.0.0.1
In-Label : 3
Out-Label : NULL
In-Interface : ----------
Out-Interface : ----------
LspIndex : 72704
Token : 0x0
FrrToken : 0x0
LsrType : Egress
Outgoing token : 0x0
Label Operation : POP
Mpls-Mtu : ------
TimeStamp : 204745sec
Bfd-State : ---
BGPKey : ------
No : 2

Equipment
VrfIndex :
Fec : 2.2.2.2/32
Nexthop : 192.168.1.2
In-Label : NULL
Out-Label : 3
Out-Interface : GigabitEthernet0/2/0
LspIndex : 72705
Token : 0x8000007
FrrToken : 0x0
LsrType : Ingress
Label Operation : PUSH
Mpls-Mtu : ------
TimeStamp : 944sec
Bfd-State : ---
BGPKey : ------
No : 3
VrfIndex :
Fec : 2.2.2.2/32
Nexthop : 192.168.1.2
In-Label : 1656
Out-Label : 3
LspIndex : 72706
Token : 0x8000008
FrrToken : 0x0
LsrType : Transit
Label Operation : SWAP
Mpls-Mtu : ------
TimeStamp : 944sec
Bfd-State : ---
BGPKey : ------
No : 4
VrfIndex :
Fec : 3.3.3.3/32
Nexthop : 192.168.1.2
In-Label : NULL
Out-Label : 2075
LspIndex : 72707
Token : 0x8000009
FrrToken : 0x0
LsrType : Ingress
Label Operation : PUSH
Mpls-Mtu : 1500
TimeStamp : 944sec
Bfd-State : ---
BGPKey : ------
No : 5
VrfIndex :
Fec : 3.3.3.3/32
Nexthop : 192.168.1.2
In-Label : 1657
Out-Label : 2075
LspIndex : 72708
Token : 0x800000a
FrrToken : 0x0

Equipment
LsrType : Transit
Label Operation : SWAP
Mpls-Mtu : 1500
TimeStamp : 944sec
Bfd-State : ---
BGPKey : ------
The boldfaced items in the command output show the LDP LSP lifetime. If the lifetime is too
short, LSP flapping may occur.
Step 7 Run the ping lsp command to check the LSP connectivity and whether LSP forwarding is normal.
<HUAWEI> ping lsp -a 1.1.1.1 ip 3.3.3.3 32
LSP PING FEC: IPV4 PREFIX 3.3.3.3/32 : 100 data bytes, press CTRL_C to
break
Reply from 3.3.3.3: bytes=100 Sequence=1 time = 26 ms
--- FEC: IPV4 PREFIX 3.3.3.3/32 ping statistics ---

0.00% packet loss
This step is to check that the packets to loopback0 on CX600 B are transmitted along an LSP.
All the PEs related to services need to be checked.
----End
Troubleshooting
If the established LDP session is in the Down state on an LDP-deployed network, complete the
following:
1. Check whether the interface on which the LDP session is established is shut down.
Run the display this command in the interface view. If the command output contains
shutdown, the interface is shut down.
l If the interface is shut down, run the undo shutdown command in the interface view
to start the interface.
l If the interface is not shut down, go to Step 2.
2. Check whether commands for deleting MPLS configurations have been executed.
Run the display current-configuration command to check whether commands for deleting
MPLS configurations have been executed.
l If the command output does not contain mpls, MPLS is disabled.
l If the command output does not contain mpls ldp, MPLS LDP is disabled.
l If the command output does not contain mpls ldp remote peer, the session established
with the remote LDP peer has been deleted.
l If any command for deleting MPLS configurations has been run, run corresponding
commands to restore the deleted configurations.
l If no command for deleting MPLS configurations has been run but the fault persists, go
to Step 3.

Equipment
3. Check that routes are available.

Run the display ip routing-table command and check the Destination/Mask field in the
command output to find out whether there is a route to the peer device. If there is no route
to the peer device, the TCP connection cannot be established.
l If the route to the peer device is unreachable, follow the procedure described in "The
Ping Operation Fails" in the ATNMulti-service Access Equipment Troubleshooting to
rectify the IGP route fault.
l If the route to the peer device is reachable, go to Step 4.
4. Check whether an LDP Hello-hold timer expires.
Run the display mpls ldp interface command to check that both ends of the LDP session
can send Hello messages. It is recommended that the display mpls ldp interface command
be run every 3 seconds. If the statistics on sent or received messages remain unchanged,
the transmission of Hello messages is abnormal, and the Hello-hold timer expires.
l If the Hello-hold timer expires, see the troubleshooting of high CPU usage.
l If the Hello-hold timer does not expire, go to Step 5.
5. Check whether the LDP Keepalive-hold timer expires.
Run the display mpls ldp session command to check that both ends of the LDP session
can send Keepalive messages. It is recommended that the display mpls ldp session
command be run every 5 seconds. If the statistics on sent or received messages remain
unchanged, the transmission of Keepalive messages is abnormal, and the Keepalive-hold
timer expires.
l If the Keepalive-hold timer expires, follow the procedure described in "The Ping
Operation Fails" in the ATNMulti-service Access Equipment Troubleshooting to rectify
the fault in message forwarding.
l If the Keepalive-hold timer does not expire, go to Step 6.
l Results of the preceding operation procedure.
l Configuration files, log files, and alarm files of the devices.
5.6 Commissioning MPLS TE

This section describes how to commission MPLS TE.
Prerequisite
Link Layer.
Context
On the network shown in Figure 5-7, MPLS TE is configured on the network.

Equipment
Figure 5-7 Typical networking for configuring MPLS TE

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
Procedure
Step 1 Run the display interface tunnel command on the commissioning device to view basic
information about tunnel interfaces.
<HUAWEI> display interface tunnel
Tunnel0/2/0 current state : UP
Last line protocol up time : 2010-02-05 15:12:16 UTC
+08:00
Description: HUAWEI, Quidway Series, Tunnel0/2/0 Interface
Internet Address is unnumbered, using address of LoopBack0(1.1.1.1/32)
Encapsulation is TUNNEL, loopback not set
Tunnel destination 3.3.3.3
Tunnel up/down statistics 13
Tunnel protocol/transport MPLS/MPLS, ILM is available,
primary tunnel id is 0x800000b, secondary tunnel id is 0x0
Current system time: 2010-02-05 15:16:34+08:00
300 seconds output rate 0 bits/sec, 0 packets/sec
0 seconds output rate 0 bits/sec, 0 packets/sec
0 packets output, 0 bytes
0 output error
0 output drop
ct0:0 packets output, 0 bytes
0 output error
0 packets output drop
Input bandwidth utilization : --
Output bandwidth utilization : --
The boldfaced items in the command output show that the tunnel interface status and link-layer
protocol status are both Up.
Step 2 Run the display mpls te tunnel-interface command on the commissioning device to view
information about the tunnel interfaces on the local node.
<HUAWEI> display mpls te tunnel-interface
================================================================
Tunnel0/2/0
================================================================
Tunnel State Desc : Up
Active LSP : Primary LSP
Session ID : 127
Ingress LSR ID : 1.1.1.1 Egress LSR ID: 3.3.3.3
Admin State : UP Oper State : UP
Primary LSP State : UP
Main LSP State : READY LSP ID : 7
Check that the tunnel configurations on the local node are correct. If Up is displayed in the
command output, it indicates that the tunnel has been established successfully.
Step 3 Run the display mpls te cspf tedb command to view TEDB information.
<HUAWEI> display mpls te cspf tedb all
Maximum Nodes Supported: 2000 Current Total Node Number: 3

Equipment
Maximum Links Supported: 8000 Current Total Link Number: 4

Maximum SRLGs supported: 10000 Current Total SRLG Number: 0
Id Router-Id IGP Process-Id Area Link-Count

1 1.1.1.1 ISIS 1 Level-2 1
2 2.2.2.2 ISIS 1 Level-2 2
3 3.3.3.3 ISIS 1 Level-2 1
Check that the link information in the TEDB is correct.
Step 4 Run the display mpls rsvp-te interface command on the commissioning device to view RSVP-
TE configurations on the interface.
<HUAWEI> display mpls rsvp-te interface
Interface: GigabitEthernet0/2/0
Interface Address: 192.168.1.1
Interface state: UP Interface Index: 0x2f57
Total-BW: 100000 Used-BW: 20000
Hello configured: NO Num of Neighbors: 1
SRefresh feature: DISABLE SRefresh Interval: 30 sec
Mpls Mtu: 1500 Retransmit Interval: 5000 msec
Increment Value: 1
Authentication: DISABLE
Bfd Enabled: DISABLE Bfd Min-Tx: 10
Bfd Min-Rx: 10 Bfd Detect-Multi: 3
The boldfaced items in the command output show the RSVP-TE configurations. Check whether
or not the interface enabled with RSVP-TE is configured correctly and is in the Up state. In
addition, check that the total TE bandwidth on the interface and the used TE bandwidth meet
the corresponding requirement.
Step 5 Run the display mpls rsvp-te peer command on the commissioning device to check whether
or not an RSVP-TE neighbor relationship has been established between the interfaces enabled
with RSVP-TE.
<HUAWEI> display mpls rsvp-te peer
Remote Node id Neighbor
Neighbor Addr -----
SrcInstance: 0xAAAD648C NbrSrcInstance: 0x0
PSB Count: 1 RSB Count: 2
Hello Type Sent: NONE
SRefresh Enable: NO
Last valid seq # rcvd: NULL
Interface GigabitEthernet0/2/0
Neighbor Addr: 192.168.1.2
SrcInstance: 0xAAAD648C NbrSrcInstance: 0x0
PSB Count: 2 RSB Count: 1
Hello Type Sent: NONE
SRefresh Enable: NO
Last valid seq # rcvd: NULL
Step 6 Run the ping lsp command on the commissioning device to test the availability of the TE tunnel.
<HUAWEI> ping lsp te tunnel 0/2/0
LSP PING FEC: RSVP IPV4 SESSION QUERY Tunnel0/2/0 : 100 data bytes, press CTRL_C
to break
--- FEC: RSVP IPV4 SESSION QUERY Tunnel0/2/0 ping statistics ---

Equipment
0.00% packet loss

----End
Troubleshooting
If the established TE tunnel is in the Down state on a TE-deployed network, complete the
following:
1. Check that the commit command has been executed to commit tunnel configurations.
Run the display current-configuration command on the ingress that is configured with
the TE tunnel.
l If the commit command has not been executed, run it in the tunnel view.
l If the commit command has been executed in the tunnel view, go to Step 2.
2. Check that CSPF has been successfully calculating paths.
Run the display mpls te cspf destination ip-address explicit-path path-name command
on the TE tunnel ingress. If command output is displayed, CSPF has been successfully
calculating paths; if no command output is displayed, CSPF failed to calculate a path.
l If CSPF failed to calculate a path, check that routes to the destination of the TE tunnel
exist.
If no route exists, follow the procedure described in "The Ping Operation Fails" in
the ATNMulti-service Access Equipment Troubleshooting to rectify the route fault.
If reachable routes exist and they satisfy the requirements to establish a TE tunnel,
rectify the fault by referring to the section "CSPF Calculation Fails."
l If CSPF has been successfully calculating paths but the fault persists, go to Step 3.
3. Check that RSVP is enabled on every device along the TE tunnel.
The command output of display mpls te cspf destination ip-address explicit-path path-
name in Step 2 contains a series of IP addresses. These IP addresses indicate the hops along
the TE tunnel. On the interface mapped to each IP address, run the display current-
configuration interface interface-name command to check if RSVP is enabled.
l If an interface is not enabled with RSVP, enable RSVP on the interface.
l If all interfaces are enabled with RSVP but the fault persists, go to Step 4.
4. Check that devices along the TE tunnel have been successfully exchanging RSVP Path and
Resv messages.
Run the display mpls te tunnel-interface command on the TE tunnel ingress and check
fields Ingress LSR ID, LSP ID, and Session ID in the command output. In Step 3, LSR
A, LSR B, and LSR C represent the nodes along the TE tunnel.
Complete the following to check that the RSVP Path message and RSVP Resv message
are correctly transmitted:
l Check that RSVP Path messages are correctly sent and received on every node along
the LSP in the sending direction (LSR A -> LSR B -> LSR C).
Run the display mpls rsvp-te psb-content command on every node the RSVP Path
message travels through.
If the command output is not empty on any node, it can be concluded that RSVP
Path messages are correctly sent and received between these nodes.

Equipment
If the command output is empty on a node, it can be concluded that the node fails
to receive RSVP Path messages from the upstream node.
l Check that RSVP Resv messages are correctly transmitted in the sending direction (LSR
C -> LSR B -> LSR A).
Run the display mpls rsvp-te rsb-content command on every node the RSVP Resv
message travels through.
If the command output is not empty on any node, it can be concluded that RSVP
Resv messages are correctly transmitted.
If the command output is empty on a node, it can be concluded that the node fails
to receive RSVP Resv messages from the upstream node.
l If messages fail to be properly exchanged, follow the procedure described in "The Ping
Operation Fails" in the ATNMulti-service Access Equipment Troubleshooting to rectify
the message forwarding fault.
l If messages are properly exchanged but the fault persists, go to Step 5.
5.7 Commissioning BGP/MPLS IP VPN

This section describes how to commission BGP/MPLS IP VPN.
Prerequisites
Link Layer.
Context
On the network shown in Figure 5-8, BGP/MPLS IP VPN is configured on the network.
Figure 5-8 Typical networking for commissioning BGP/MPLS IP VPN

1.1.1.1/32 2.2.2.2/32
100.1.1.1/24 192.168.1.1/24 100.1.2.1/24
GE1/0/0 GE0/2/0 GE2/0/0
GE0/2/1 192.168.1.2/24 GE2/0/0
100.1.1.2/24 GE1/0/0 100.1.2.2/24
CE1 PE1 PE2 CE2
Procedure
Step 1 Run the display ip vpn-instance verbose command on the commissioning device to check that
VPN instance configurations are correct.
<HUAWEI> display ip vpn-instance verbose
Total VPN-Instances configured : 1

Equipment
VPN-Instance Name and ID : vpna, 1

Interfaces : GigabitEthernet0/2/1
Address family ipv4
Create date : 2010/01/21 11:30:35 UTC+08:00
Up time : 0 days, 00 hours, 05 minutes and 19 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label policy: label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Log Interval : 5
Step 2 Run the display bgp peer command on the commissioning device to view BGP peer information.
<HUAWEI> display bgp vpnv4 all peer
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv

2.2.2.2 4 274 10 12 0 03:24:40 Established 0
Peer of IPv4-family for vpn
instance :
VPN-Instance vpna, router ID 1.1.1.1:
100.1.1.1 4 65410 454 418 0 03:12:16 Established 9
Check that the number of BGP peers and the number of configured VPN instances are correct.
The boldfaced items in the command output show that the BGP peer relationship is in the
Established state, indicating that a BGP peer relationship has been successfully established
between PEs.
Step 3 Run the display bgp vpnv4 routing-table command on the commissioning device to view BGP
VPNv4 routing information.
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table peer 100.1.1.1
advertised-routes

Origin : i - IGP, e - EGP, ? -
incomplete
Ogn
*>i 2.2.2.2/32 1.1.1.1 0 100 0 65420?
*> 100.1.1.0/24 0.0.0.0 0 0 ?
*>i 100.1.2.0/24 1.1.1.1 0 100 0 ?
*>i 192.168.1.0 1.1.1.1 0 100 0 65420?
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table peer 100.1.1.1 received-
routes

Ogn
*> 1.1.1.1/32 100.1.1.1 0 0 65410?
*> 2.2.2.2/32 100.1.1.1 0 0 65410?
* 100.1.1.0/24 100.1.1.1 0 0 65410?
*> 192.168.1.0 100.1.1.1 0 0 65410?

Equipment
Check that the sent and received BGP routes are correct. First check whether the routes sent by
the PE are correct, meaning whether some necessary routes are not sent but some unnecessary
routes are sent. Then do the same for the routes received from the peer PE.
Step 4 Run the display ip routing-table vpn-instance command on the commissioning device to view
the routing table of the VPN instance.
<HUAWEI> display ip routing-table vpn-instance vpna
------------------------------------------------------------------------------
Routing Tables: vpna
100.1.1.0/24 Direct 0 0 D 10.1.1.2 GigabitEthernet0/2/1
100.1.2.0/24 BGP 255 0 RD 2.2.2.2 GigabitEthernet0/2/0
The command output shows whether the received BGP routes are injected into the routing table
of the VPN instance. If BGP routes are received but are not injected into the routing table of the
VPN instance, the probable cause is that the public network tunnel is not established, or the
routes are filtered by a routing policy. The boldfaced items in the command output show the
route to the interface on the remote CE.
Step 5 Run the ping command on CE1 to test the connectivity of the link between CE1 and CE2.
<HUAWEI> ping -vpn-instance vpna 100.1.2.2

0.00% packet loss
The preceding command output shows that two CEs in the same VPN can communicate with
each other.
----End
Troubleshooting
If BGP traffic in the VPN is interrupted, complete the following:
1. Check that next hops of routes are reachable.
Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table ipv4-
address [ mask | mask-length ] command on the PE that sends routes (the local PE) to check
that the target route exists. ipv4-address specifies the prefix of the target route.
l If the target route does not exist, check whether the route of a CE is advertised to the
local PE.
l If the target route exists, check that it is active. The following is an example:
Assume that the target route is a route to 1.1.1.1/32. The following command output shows
that this route is active and selected. The original next hop and iterated next hop of this
route are 3.3.3.3 and 20.1.1.2 respectively.

Equipment
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1

Imported route.
From: 20.1.1.1 (1.1.1.1)
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid,
internal, best, select, active, pre 255
l If the target route is inactive, check whether there is a route to the original next hop in
the IP routing table. If there is no route to the original next hop, the BGP route is not
advertised, because its next hop is unreachable. Then, find out why there is no route to
the original next hop (this fault is generally associated with IGP or static routes).
l If the target route is active but not selected, check whether there is a route with a higher
protocol preference in the IP routing table. If there is a route with a higher protocol
preference, import it into BGP or adjust its protocol preference. If there is no route with
a higher protocol preference, contact Huawei technical support personnel.
NOTE
In the BGP routing table, multiple routes may have the same prefix. One of these routes can be
selected at most, and only the selected route is added to the IP routing table and sent to the peer.
When an optimal route needs to be selected from among BGP routes and other protocol routes,
the route with the highest protocol preference is selected.
l If the target route is active but not selected, contact Huawei technical support personnel.
NOTE
If there are active BGP routes, one of them is preferred.

l If the target route is active and selected but there is no information indicating that this
route is sent to the remote PE, perform Step 2 to check the outbound policy applied to
the local PE.
Run the display bgp vpnv4 all routing-table network { mask | mask-length } command
on the remote PE to check that it has received the target route.
If the remote PE has received the target route, perform Step 1 again to check whether
the next hop of the route is reachable and whether this route is selected.
If the remote PE has not received the target route, perform Step 2 to check the
inbound policy applied to the remote PE.
2. Check that the routing policies are configured correctly.
Run the display current-configuration configuration bgp command on the local PE and
remote PE to check that inbound and outbound policies are configured.
NOTE
You only need to focus on peers of the BGP-VPNv4 address family or BGP-VPN instance address
family when private network traffic is interrupted.
<HUAWEI> display current-configuration configuration bgp
#
bgp 100
peer 1.1.1.1 as-number 200

Equipment
peer 2.2.2.1 connect-interface LoopBack0

#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 1.1.1.1 filter-policy acl-name acl-name import
peer 1.1.1.1 filter-policy acl-name acl-name export
peer 1.1.1.1 as-path-filter 1 import
peer 1.1.1.1 as-path-filter 1 export
peer 1.1.1.1 ip-prefix prefix-name import
peer 1.1.1.1 ip-prefix prefix-name export
peer 1.1.1.1 route-policy policy-name import
peer 1.1.1.1 route-policy policy-name export
#
ipv4-family vpn-instance vpna
import-route direct
peer 10.1.1.1 filter-policy acl-name acl-name import
peer 10.1.1.1 filter-policy acl-name acl-name export
peer 10.1.1.1 as-path-filter 1 import
peer 10.1.1.1 as-path-filter 1 export
peer 10.1.1.1 ip-prefix prefix-name import
peer 10.1.1.1 ip-prefix prefix-name export
peer 10.1.1.1 route-policy policy-name import
peer 10.1.1.1 route-policy policy-name export
#
return
l If inbound and outbound policies are configured on the two devices, you need to check
whether the target route is filtered by these policies. For detailed configurations of a
routing policy, see the ATN Multi-service Access Equipment Configuration Guide - IP
Routing.
l If inbound and outbound policies are not configured on the two ends, go to Step 3.
3. Check that routes can be iterated to a tunnel.
Run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command
on the remote PE to check whether the target route can be iterated to a tunnel.
Assume that the target route is a route to 50.1.1.2/32. If the Relay Tunnel Out-Interface
field and Relay token field in the command output are not empty, this route can be iterated
to a tunnel.
<HUAWEI> display bgp vpnv4 all routing-table 50.1.1.2
Total routes of Route Distinguisher(1:2): 1
Imported route.
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Out-Interface: GigabitEthernet0/2/0
Relay token: 0x1002
Ext-Community:RT <1 : 1>
internal, best, select, pre 255

Equipment

Imported route.
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Out-Interface: GigabitEthernet0/2/0
Relay token: 0x1002
internal, best, select, active, pre 255
l If the target route fails to be iterated to a tunnel, check that the associated tunnel exists
and MPLS LDP is configured correctly. For more information, see the section "MPLS"
in ATNMulti-service Access Equipment Troubleshooting.
l If the target route can be iterated to a tunnel, go to Step 4.
4. Check whether routes fail to be added to the VPN routing table because the configured
import RT and export RT do not match.
Run the display current-configuration configuration vpn-instance command on the
local PE and remote PE to check if routes fail to be added to the VPN routing table of the
remote PE after being sent to the remote PE because the export RT of the local VPN instance
does not match the import RT of the remote VPN instance.
export-extcommunity indicates an export RT, and import-extcommunity indicates an
import RT.
<HUAWEI> display current-configuration configuration vpn-instance
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 1:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
apply-label per-instance
vpn-target 1:1 export-extcommunity vpn-target 1:1 import-extcommunity
ip vpn-instance vpnb
ipv4-family
route-distinguisher 1:2
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
#
return
l If the export RT of the local VPN instance does not match the import RT of the remote
VPN instance, configure matching VPN-targets in the VPN instance.
l If the export RT of the local VPN instance matches the import RT of the remote VPN
instance, go to Step 5.
5. Check that the number of labels does not exceed the limit.
Check that MPLS is enabled on the local PE. Then, run the display bgp vpnv4 all routing-
table ipv4-address [ mask | mask-length ] command to check whether the target route has
been assigned a VPN label.
If there is no Label information field in the command output, labels may be insufficient.
As a result, the target route is not assigned a label and is not advertised to the peer.
<HUAWEI> display bgp vpnv4 all routing-table 100.1.1.1
Total routes of Route Distinguisher(1:1): 1

Equipment

Imported route.
Label information (Received/Applied): NULL/13312
From: 0.0.0.0 (0.0.0.0)
Ext-Community:RT <1 : 1>
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select,
pre 255
1.1.1.1

Imported route.
From: 0.0.0.0 (0.0.0.0)
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best,
select,pre 0
l If labels are insufficient, run the apply-label per-instance command in the VPN
instance view to configure the device to assign a label to each instance to save labels.
You can also configure route summarization to reduce the number of routes.
l If labels are sufficient, go to Step 6.
6. Check that the number of routes does not exceed the limit.
Run the display current-configuration configuration bgp | include peer destination-
address command and the display current-configuration configuration bgp | include
peer group-name command (if the peer is added to a peer group) on the remote PE to check
whether the limit on the number of routes to be received is configured on the remote PE.
For example, if the limit is set to 5, subsequent routes are dropped and a log is recorded
after the remote PE receives five routes from the local PE at 1.1.1.1.
<HUAWEI> display current-configuration configuration bgp | include peer
1.1.1.1
peer 1.1.1.1 route-limit 5 alert-only
peer 1.1.1.1 enable
If the peer is added to a peer group, there may be no configurations about the route limit
in the command output.
<HUAWEI> display current-configuration configuration bgp | include peer
1.1.1.1
peer 1.1.1.1 group IBGP
peer 1.1.1.1 enable
In this case, you need to run the display current-configuration configuration bgp |
include peer group-name command to check the configurations of this peer group.
<HUAWEI> display current-configuration configuration bgp | include peer IBGP
peer IBGP route-limit 5 alert-only
peer IBGP enable
If the log BGP/3/ROUTPRIX_EXCEED is generated when traffic is interrupted, the target

route is dropped because the route limit has been exceeded, and the limit needs to be
increased.

Equipment
NOTE
Changing the limit on the number of routes to be received from a peer interrupts the BGP peer
relationship. Therefore, it is recommended to reduce the number of sent routes by configuring route
summarization on the local device.
5.8 Commissioning VPWS

This section describes how to commission VPWS.
Prerequisite
Link Layer.
Context
On the network shown in Figure 5-9, VPWS is deployed on the network and ATN is a PE.
Figure 5-9 Typical networking for commissioning VPWS

1.1.1.1/32 2.2.2.2/32
100.1.1.1/24 192.168.1.1/24 100.1.1.2/24
GE1/0/0.1 GE0/2/0 GE2/0/0.1
GE0/2/1.1 192.168.1.2/24 GE2/0/0.1
GE1/0/0
CE1 PE1 PE2 CE2
Procedure
Step 1 Run the display mpls l2vc command on the commissioning device to view information about
the L2VCs using the LDP as the signaling protocol.
<HUAWEI> display mpls l2vc
total LDP VC : 1 1 up 0 down
*client interface : GigabitEthernent0/2/1.1
Administrator PW : up
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 101
VC type : VLAN
forwarding entry : existent
local group ID : 0

Equipment

link state : up
tunnel policy name : to2
PW template name : --
VC last up time : 2010/07/24 12:31:31
CKey : 16
NKey : 15
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : --
Domain Name : --
The command output shows L2VC information. Check that the number of Up L2VCs is correct,
the AC interface of each L2VC is correctly configured, and the AC status, VC status, session
status, link status, VC ID, encapsulation type, and destination address of the L2VC are correct.
Step 2 Run the display l2vpn ccc-interface vc-type command on the commissioning device to view
information about the interfaces that had set up an L2VPN connection.
<HUAWEI> display l2vpn ccc-interface vc-type all
Total ccc-interface of LDP VC: 1
up (1), down (0)
Interface Encap Type State VC Type
GigabitEthernet1/0/0.1 vlan up ldp-vc
The command output shows information about the interfaces that had set up an L2VPN
connection. Check that the encapsulation type, status, and VC type of the interfaces are correct.

0.00% packet loss
each other.
----End
Troubleshooting
If the VC of a Martini VLL cannot become Up, complete the following:
1. Check that the two ends of the VC are configured with the same encapsulation type and
MTU.

Equipment
Run the display mpls l2vc vc-id command to view VC information.

<HUAWEI> display mpls l2vc 102
*client interface : GigabitEthernet0/2/1.5
session state : up
AC status : up
VC state : up
VC ID : 102
VC type : VLAN
local group ID : 0
link state : up
VC last up time : 2010/02/17 08:23:07
CKey :
16
NKey : 15
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the two ends are configured with different encapsulation types or MTUs, change the
encapsulation type or MTU of one end to be the same as that of the other.
If the two ends are configured with the same encapsulation type and MTU but the fault
persists, go to Step 2.
NOTE
A VC can only be Up when the two ends of the VC are configured with the same encapsulation type
and MTU.
2. Check that the VC IDs of the two ends of the VC are the same.
session state : up
AC status : up
VC state : up
VC ID : 102
VC type : VLAN
local group ID : 0
link state : up

Equipment

VC last up time : 2010/02/17 08:23:07
CKey :
16
NKey : 15
Service Class : --
Color : --
DomainId : --
Domain Name : --
If the VC IDs of the two ends of the VC are different, change the VC ID of one end to be
the same as that of the other.
If the VC IDs of the two ends of the VC are the same but the fault persists, go to Step 3.
NOTE
A VC can only be Up when the VC IDs of the two ends of the VC are the same.
3. Check that the LDP session between the two ends is Up.
session state : up
AC status : up
VC state : up
VC ID : 102
VC type : VLAN
local group ID : 0
link state : up
VC last up time : 2010/02/17 08:23:07
CKey :
16
NKey : 15
Service Class : --
Color : --
DomainId : --
Domain Name : --

Equipment
If the LDP session is Down, see the section "LDP Session Goes Down" in ATN Multi-
service Access Equipment Troubleshooting to locate the fault and make the LDP session
Up.
If the LDP session is Up, go to Step 4.
NOTE
A VC can only be set up when the LDP session is Up.

4. Check that the PW has selected a tunnel.
Run the display mpls l2vc vc-id command.
l Check the VC tunnel/token info field in the command output. If VC tunnel/token
info is displayed as 0 tunnels/tokens, no tunnel has been selected by the PW.
l Check the tunnel policy name field in the command output.
If tunnel policy name is displayed as -, an LDP LSP is used as the tunnel for the
PW, or no tunnel policy is configured. An MPLS TE tunnel can only be used for a
PW after a tunnel policy is configured.
If tunnel policy name is not displayed as "-", a tunnel policy has been adopted. In
this case, run the display this command in the tunnel policy view to view the tunnel
policy configuration.
[HUAWEI-tunnel-policy-p1] display this
#
tunnel-policy p1
tunnel select-seq cr-lsp load-balance-number 1
#
NOTE
If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is

configured in the tunnel policy view, you also need to run the mpls te reserved-for-binding
command on the tunnel interface.
If the tunnel is Down, see the section "TE Tunnel Is Down" in ATNMulti-service Access
Equipment Troubleshooting to locate the fault and make the tunnel Up. If the tunnel is Up
and the TE interfaces are correctly configured, go to Step 5.
NOTE
A VC can only be Up when the tunnel that bears the VC is also Up.
5. Check that the AC interfaces on the two ends are Up.
Run the display mpls l2vc vc-id command on the two ends of the VC to check whether or
not the AC status field is displayed as Up.
l If the AC interfaces on the two ends are Down, see the section "Physical Connection
and Interfaces" in ATN Multi-service Access Equipment Troubleshooting to locate the
fault and make the AC interfaces Up.
l If the AC interfaces on the two ends are Up, go to Step 6.
NOTE
A VC can only be Up when the AC interfaces on the two ends of the VC are also Up.

Equipment
5.9 Commissioning VPLS

This section describes how to commission VPLS.
Prerequisite
Link Layer.
Context
On the network shown in Figure 5-10, VPLS is deployed on the network and ATN A is a PE.
Figure 5-10 Typical networking for commissioning VPLS

1.1.1.1/32 2.2.2.2/32
100.1.1.1/24 192.168.1.1/24 100.1.1.2/24
GE1/0/0.1 GE0/2/0 GE2/0/0.1
GE0/2/1.1 192.168.1.2/24 GE2/0/0.1
GE1/0/0
CE1 PE1 PE2 CE2
Procedure
Step 1 Run the display vsi command on the commissioning device to view VSI information.
<HUAWEI> display vsi name v1 verbose
***VSI Name : v1
Administrator VSI : no
Isolate Spoken : disable
VSI Index : 1
PW Signaling : ldp
Member Discovery Style : static
PW MAC Learn Style : unqualify
Encapsulation Type : vlan
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
Ignore AcState : disable
Multicast Fast Swicth : enable
Create Time : 0 days, 0 hours, 50 minutes, 23 seconds
VSI State : up
VSI ID : 10
*Peer Router ID : 2.2.2.2
ignore-standby-state : no
VC Label : 23552
Peer Type : dynamic
Session : up
Tunnel ID : 0x10002000

Equipment
Broadcast Tunnel ID : 0x10002000

Broad BackupTunnel ID : 0x0
CKey : 6
NKey : 5
StpEnable : 0
PwIndex : 0
Interface Name : GigabitEthernet0/2/1.1

State : up
Last Up Time : 2010/08/15 15:41:59
Total Up Time : 0 days, 0 hours, 19 minutes, 18 seconds
**PW Information:
*Peer Ip Address : 2.2.2.2

PW State : up
Local VC Label : 23552
Remote VC Label : 23552
PW Type : label
Tunnel ID : 0x10002000
Broadcast Tunnel ID : 0x10002000
Broad BackupTunnel ID : 0x0
Ckey : 0x6
Nkey : 0x5
Main PW Token : 0x10002000
Slave PW Token : 0x0
Tnl Type : LSP
OutInterface :
Backup OutInterface :
Stp Enable : 0
Mac Flapping : 0
PW Last Up Time : 2010/08/15 15:41:59
PW Total Up Time : 0 days, 0 hours, 15 minutes, 3 seconds
Pay attention to the values of boldfaced fields displayed.

l PW Signaling is the signaling type of the PW, which can be LDP or BGP. ATN only supports
LDP.
l Member Discovery Style is the member discovery mode, which can be dynamic or static
discovery. ATNonly supports static discovery.
l Encapsulation Type is the encapsulation type for the VSI, or the encapsulation type of the
packets transmitted over the VC.
l VSI State is the VSI status. The VSI status should be Up after a VPLS connection is
established successfully.
l State is the status of the AC bound to the VSI. The AC status should be Up after a VPLS
connection is established successfully.
l Peer Ip Address is the IP address of a peer.
l PW State is the PW status. The PW status should be Up after a VPLS connection is
established successfully.
Step 2 Run the display vpls forwarding-info command on the commissioning device to view
forwarding information of all VSIs.
<HUAWEI> display vpls forwarding-info
Total Number : 2, 2 up, 0 down
Vsi-Name PeerIP VcOrSiteId PwState

V1 2.2.2.2 1 UP

Equipment
The command output shows forwarding information of all VSIs. Check that the PW status of
each VSI is Up.
Step 3 Run the display l2vpn vsi-list tunnel-policy command on the commissioning device to view
the tunnel policy name used in each VSI.
<HUAWEI> display l2vpn vsi-list tunnel-policy p1
Using Tunnel-Policy p1 VSI Instance statistics:
----------------------------------------------------------------------
vsi v1

0.00% packet loss
each other.
----End
Troubleshooting
If the VSI of Martini VPLS cannot become Up, complete the following:
1. Check that the encapsulation types of the two ends are the same.
<HUAWEI> display vsi name tt
Vsi Mem PW Mac Encap Mtu Vsi
Name Disc Type Learn Type Value State
--------------------------------------------------------------------------
tt static ldp unqualify vlan 1500 up
l If the encapsulation types of the two ends are different, run the encapsulation
{ ethernet | vlan } command in the VSI view to change the encapsulation type of one
end to be the same as that of the other.
l If the encapsulation types of the two ends are the same, go to Step 2.
NOTE
A VSI can only be Up when the encapsulation types configured for both ends are the same.
2. Check that MTUs of the two ends are the same.
<HUAWEI> display vsi name tt
Vsi Mem PW Mac Encap Mtu Vsi
Name Disc Type Learn Type Value State
--------------------------------------------------------------------------
tt static ldp unqualify vlan 1500 up
l If the MTUs of the two ends are different, run the mtu mtu-value command in the VSI
view to change the MTU of one end to be the same as that of the other.
l If the MTUs of the two ends are consistent, go to Step 3.

Equipment
NOTE
A VSI can only be Up when MTUs configured for both ends are the same.
3. Check that the VSI IDs or negotiation-VC-IDs of the two ends are the same.
<HUAWEI> display vsi name tt verbose
***VSI Name : tt
VSI Index : 3
PW Signaling : ldp
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
Tunnel Policy Name : p1
VSI State : up
VSI ID : 101
VC Label : 187393
Peer Type : dynamic
Session : up
Tunnel ID : 0xc0060401
Broadcast Tunnel ID : 0xc0060401
CKey : 6
NKey : 5
StpEnable : 0
PwIndex : 0

State : up
Last Up Time : 2010/02/05 06:36:57
l If the VSI IDs or negotiation-VC-IDs configured for both ends are different, run the
pwsignal ldp command in the VSI-LDP view to change the VSI ID on one end, or run
the peer peer-address negotiation-vc-id vc-id command in the VSI-LDP view to
change the negotiation-VC-ID on one end, ensuring that the VSI IDs or negotiation-
VC-IDs of the two ends are the same.
l If the VSI IDs or negotiation-vc-ids of the two ends are the same, go to Step 4.
NOTE
A VSI can only be Up when the VSI IDs or negotiation-VC-IDs of the two ends are the same.
4. Check that the LDP session between the two ends is Up.
Run the display vsi namevsi-name verbose command to check whether or not the
Session field is displayed as Up.
<HUAWEI> display vsi name tt verbose
***VSI Name : tt
VSI Index : 3
PW Signaling : ldp

Equipment

MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
Tunnel Policy Name : p1
VSI State : up
VSI ID : 101
VC Label : 187393
Peer Type : dynamic
Session : up
Tunnel ID : 0xc0060401
Broadcast Tunnel ID : 0xc0060401
CKey : 6
NKey : 5
StpEnable : 0
PwIndex : 0

State : up
Last Up Time : 2010/02/05 06:36:57
l If the LDP session between the two ends is Down, see the section "LDP Session Goes
Down" in ATN Multi-service Access Equipment Troubleshooting to locate the fault and
make the LDP session Up.
l If the LDP session between the two ends is Up, go to Step 5.
NOTE
The two ends can only perform L2VPN negotiation after the LDP session is in the Up state.
5. Check that the VSI has selected a tunnel.
Run the display vsi name vsi-name verbose command.
l Check whether or not the Tunnel ID field is displayed as 0x0. If the Tunnel ID field
is displayed as 0x0, the VSI has not selected a tunnel.
l Check the Tunnel Policy Name field. If this field is not displayed, the VSI has selected
an LDP LSP, or no tunnel policy is configured for the VSI. If the VSI selects an MPLS-
TE tunnel, the tunnel policy must be configured. The Tunnel Policy Name field value
indicates the VSI tunnel policy. You can see details of the tunnel policy by running the
display this command in the corresponding tunnel policy view.
[HUAWEI-tunnel-policy-p1] display this
#
tunnel-policy p1
tunnel select-seq cr-lsp load-balance-number 1
#
NOTE
If the tunnel binding destinationdest-ip-address te { tunnel interface-number } command is

configured in the tunnel policy view, you also need to run the mpls te reserved-for-binding
command on the tunnel interface.
If the tunnel between the two ends is Down, see the section "TE Tunnel Is Down" in
ATN Multi-service Access Equipment Troubleshooting to locate the fault and make the
tunnel Up. If the tunnel between the two ends is Up and the TE interface is correctly
configured, go to Step 6.

Equipment
NOTE
A VSI can only be Up when the tunnel between the two ends is also in the Up state.
6. Check that the AC interfaces on the two ends are Up.
Run the display vsi name vsi-name verbose command on the two ends to check that the
state of the interface corresponding to the Interface Name field is displayed as Up.
l If the AC interfaces on the two ends are Down, see the section "Physical Connection
and Interfaces" in ATN Multi-service Access Equipment Troubleshooting to locate the
fault and make the AC interfaces Up.
l If the AC interfaces on the two ends are Up, go to Step 7.
NOTE
A VSI can only be Up when AC interfaces on the two ends are also in the Up state.
5.10 Commissioning BFD

This section describes how to commission BFD.
BFD sessions can quickly detect link faults on a network.
Prerequisite
Link Layer.
Context
On the network shown in Figure 5-11, BFD is configured on the network.
Figure 5-11 Typical networking for commissioning BFD

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
Procedure
Step 1 Run the display current-configuration command on the commissioning device to check if BFD
parameters have taken effect.
<HUAWEI> display current-configuration | begin peer-ip
bfd to_net_comm bind default-ip interface GigabitEthernet0/2/0
discriminator local 1
discriminator remote 2

Equipment
detect-multiplier 10
wtr 5
process-interface-status
process-pst
commit
If a single-hop BFD session is set up, process-pst must be configured. The boldfaced items in
the command output show that process-pst has been configured.
Step 2 Run the display bfd session command on the commissioning device to view BFD session
information.
<HUAWEI> display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
1 2 192.168.0.2 Up S_IP_IF GigabitEthernet0/2/0
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
The boldfaced items in the command output show the BFD session information. Check that the
number of BFD sessions is correct, the BFD session status is Up, and the values of Local and
Remote are correct.
<HUAWEI> display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 16384 (One Hop) State : Up Name : atob
--------------------------------------------------------------------------------
Local Discriminator : 1 Remote Discriminator : 2
Session Detect Mode : Asynchronous Mode Without Echo Function
BFD Bind Type : Interface(GigabitEthernet0/2/0)
Bind Session Type : Static
Bind Peer Ip Address : 192.168.1.2
NextHop Ip Address : 192.168.1.2
Bind Interface : GigabitEthernet0/2/0
FSM Board Id : 7 TOS-EXP : 7
Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10
Actual Tx Interval (ms): 12500 Actual Rx Interval (ms): 12500
Local Detect Multi : 10 Detect Interval (ms) : 100
Echo Passive : Disable Acl Number : -
Destination Port : 3784 TTL : 255
Proc interface status : Enable Process PST : Disable
WTR Interval (ms) : 300000
Active Multi : 3
Last Local Diagnostic : Neighbor Signaled Session Down(Receive AdminDown)
Bind Application : IFNET
Session TX TmrID : - Session Detect TmrID : -
Session Init TmrID : - Session WTR TmrID : -
Session Echo Tx TmrID : -
PDT Index : FSM-130000 | RCV-0 | IF-130000 | TOKEN-0
Session Description : -
----------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
The boldfaced items in the command output show that after single-hop BFD is enabled, a single-
hop BFD session is set up in the Up state. If multi-hop BFD is enabled, the command output
will show that a multi-hop BFD session is set up in the Up state. If the BFD is associated with
interface status successfully, the Proc interface status field will be displayed as Enable.
----End
Troubleshooting
If the BFD session cannot become Up, complete the following:

Equipment
1. Run the display current-configuration configuration bfd-session command to check

whether or not BFD session configurations have been committed.
l If the commit field is displayed, BFD session configurations have been committed.
Then go to Step 2.
l If the commit field is not displayed, BFD session configurations have not been
committed. In this case, run the commit command in the BFD session view, and then
run the display bfd session all command to check that the BFD session is Up.
If the State field is displayed as Up, the BFD session has been created and no action
is required.
If the State field is not Up, go to Step 2.
2. Run the display bfd statistics session all command repeatedly to check statistics about
BFD packets.
l If the Received Packets value does not increase, go to Step 3.
l If the Send Packets value does not increase, go to Step 4.
l If both the Received Packets and Send Packets values increase properly, go to Step 7.
l If none of the Received Packets, Send Packets, Received Bad Packets, and Send Bad
Packets values increases, go to Step 5.
l If the Down Count value increases, the BFD session flaps. In this case, go to Step 5.
3. Run the display bfd statistics session all command repeatedly to check that the Received
Bad Packets value increases properly.
l If the Received Bad Packets value increases, the local end receives but discards the
BFD packets sent from the remote end. In this case, go to Step 7.
l If the Received Bad Packets value does not increase, the local end does not receive
BFD packets. In this case, go to Step 5.
4. Run the display bfd statistics session all command repeatedly to check that the Send Bad
Packets value increases properly.
l If the Send Bad Packets value increases, the BFD packets are sent but discarded. In
this case, go to Step 7.
l If the Send Bad Packets value does not increase, the local end does not send BFD
packets to the remote end. In this case, go to Step 5.
5. Run the display bfd statistics session all command repeatedly. If the BFD session still
does not go Up, run the ping command on one end to ping the other end of the BFD session.
l If the ping fails, follow the procedure described in "The Ping Operation Fails" in the
ATNMulti-service Access Equipment Troubleshooting to rectify the packet forwarding
fault.
l If the ping succeeds, go to Step 6.
6. Run the display current-configuration configuration bfd-session command to check the
min-tx-interval and min-rx-interval values and determine whether or not the detection
time value is larger than the delay value.
l If the detection time value is smaller than the delay value, run the detect-multiplier,
min-rx-interval, or min-tx-interval command to change the detection time value of
the BFD session to be larger than the delay value.
l If the detection time value of the BFD session is larger than the delay value, go to Step
7.

Equipment
5.11 Commissioning a DCN

To commission a DCN, users must configure routing protocols based on the network plan. This
section describes how to commission a DCN.
Prerequisites
The ATN device to be commissioned is running properly.
l 3 Checking the Hardware is completed.
l 4 Commissioning the Link Layer is completed.
l The ATN device is connected to the CX600 device through its DCN-enabled interface.
l The DCN-enabled interface on the ATN device is up.
Context
Figure 5-12 Typical networking diagram for DCN commissioning

NEID:0x11111 NEID:0x22222
NEIP:128.1.17.17 NEIP:128.2.34.34
GE1/0/0
PC
ATNA CX600B
Procedure
Step 1 On the ATN device, run the display dcn brief command to view the DCN information about
the ATN device.
<HUAWEI> display dcn brief
------------------------------------------------
NE-ID: 0x11111
NE-IP: 128.1.17.17
Mask: 255.255.0.0
DCN-Interface: LoopBack1023
Auto-Report: Disable
------------------------------------------------
Step 2 On the ATN device, run the display current-configuration command to view the default DCN
configurations.

Equipment

#
ip dcn vpn-instance __dcn_vpn__
ipv4-family
#
#
interface LoopBack1023
description DCN loopback interface
ip binding vpn-instance __dcn_vpn__
ip address 128.1.17.17 255.255.0.0
#
#
ospf 65534 vpn-instance __dcn_vpn__
description DCN ospf create by default
opaque-capability enable
vpn-instance-capability simple
area 0.0.0.0
network 0.0.0.0
255.255.255.255
#
The information displayed in the command output includes the VPN information, loopback
interface information, and OSPF process information created for the DCN.
Step 3 On the ATN device, run the display dcn interface command to view DCN interface information.
<HUAWEI> display dcn interface
total 8 DCN Physical interface
--------------------------------------------------------------------------
interface Vid state logical-if
--------------------------------------------------------------------------
GE0/2/0 0 down (Ready)
GE0/2/1 0 down (Ready)
Eth0/2/2 0 up (Ready) DCN-Serial0/2/2:0 (Ready)
Eth0/2/3 0 *down (Ready)
Eth0/2/4 0 up (Disable)
Eth0/2/5 0 up (Ready)
Eth0/2/6 0 up (Ready)
Eth0/2/7 0 up (Disable)
--------------------------------------------------------------------------
The text in bold displayed in the command output means that the DCN PPPoE negotiation is
successful and the virtual DCN interface has been created.
Step 4 On the ATN device, run the display ip routing-table command to view information displayed
in the DCN routing table.
<HUAWEI> display dcn ne-info
------------------------------------------------------------------------------
Routing Tables: __dcn_vpn__
128.1.0.0/16 Direct 0 0 D 128.1.17.17 LoopBack1023

128.2.34.34/32 Direct 0 0 D 128.2.34.34 DCN-
Serial0/2/2:0
The text in bold displayed in the command output represents the DCN route that has been
established to the peer end during DCN negotiation.
Step 5 On the ATN device, run the ping command to test the connectivity of the DCN route.

Equipment
<HUAWEI> ping -vpn-instance __dcn_vpn__ 128.2.34.34

Reply from 128.2.34.34: bytes=56 Sequence=1 ttl=255 time=1
ms
ms
ms
ms
ms

5 packet(s)
transmitted
5 packet(s)
received
0.00% packet
loss
The command output shows that the communication between the ATN device and CX600 is
normal.
Step 6 On the ATN device, run the telnet command to test the connectivity of the DCN route.
<HUAWEI> telnet -vpn-instance __dcn_vpn__ 128.2.34.34
Trying 128.2.34.34 ...
Press CTRL+K to
abort
Connected to
128.2.34.34 ...
Warning:
There is a risk on the user-interface which you login
through.
Please change the configuration of the user-interface as soon as
possible.
Info: The max number of VTY users is 20, and the

number
of current VTY users on line is
3.
The current login time is 2012-04-20 11:18:14.
The command output shows that the ATN device successfully telnets to the CX600.
----End

Equipment on the network are correctly connected and DCN is correctly configured, but the
ATN device fails to telnet to the CX600. In this situation, perform the following steps to handle
the fault:
1. Run the ping command to check the connectivity between the ATN device and the CX600.
If the ATN device successfully pings the CX600, contact your local Huawei technical
support engineers to diagnose the telnet fault.
2. If the ATN device fails to ping the CX600, run the display ip routing-table command to
check whether a DCN route is available between them. If there is a DCN route, contact
your local Huawei technical support engineers to diagnose the ping fault.

Equipment
3. If there is no DCN route, run the display dcn interface command to check whether the
virtual DCN interface has been established. If there is a virtual DCN interface, contact your
local Huawei technical support engineers to diagnose the OSPF route fault.
4. If there is no virtual DCN interface, run the display dcn brief command on the ATN and
CX600 devices to check whether there is a DCN NEID conflict, whether the NEIP is correct,
and whether the DCN is enabled. If there is any error, correct it. In addition, run the display
current-configuration command on the ATN device to check whether the default DCN
configurations are correct. If there are errors in the configurations, correct the errors.
5. If the fault persists, collect the following information and contact Huawei technical support
personnel.
5.12 Commissioning Clocks

This section describes how to commission clocks.
Prerequisites
3 Checking the Hardware has been completed and the ATN device to be commissioned is
running properly.
Context
Figure 5-13 Typical networking diagram for clock commissioning

1.1.1.1/32 2.2.2.2/32
192.168.1.1 / 24
Console GE0/2/0
network
GE1/0/0 POS3/0/0
192.168.1.2 / 24 192.167.1.10 / 24
PC
ATNA CX600B
Procedure
Step 1 On the ATN device, run the display clock source command to view information about the clock
source.
<HUAWEI> system
[HUAWEI] display clock source
System trace source State: lock mode
into pull-in range
Current system trace source: FE0/2/0
Current 2M-1 trace source: system PLL
Current 2M-2 trace source: system PLL

Equipment
Frequency lock success: yes
Master board
Source Pri(sys/2m-1/2m-2) In-SSM Out-SSM State Ref Source
-----------------------------------------------------------------------------
FE0/2/0 ---/---/--- dnu prc normal No
FE0/2/1 100/---/--- dnu prc initial Yes
FE0/2/2 1 /---/--- prc dnu normal Yes
FE0/2/3 1 /---/--- prc prc normal Yes
If the ATN device is in the downstream direction, it must synchronize to the clock of the upstream
device. In this case, check the text in bold displayed in the command output to determine whether
the clock source is correct and whether the ATN device synchronizes to this clock source. If the
clock source is empty or not the expected one, ensure that the clock source is correctly configured
for the ATN device. If the 2M external clock loop is used, ensure that the 2M-1 or 2M-2 clock
source is correctly configured for the ATN device and the ATN device has correctly
synchronized to the clock source.
Step 2 On the ATN device, run the display ptp all command to view the IEEE 1588v2 time information.
<HUAWEI> system
[HUAWEI] display ptp all
Device config info
------------------------------------------------------------------------
PTP state :enabled Domain value :0
Slave only :no Device type :BC
Set port state :no Local clock ID :000000fffe000001
ACR :no Virtual clock ID :no
Time lock success :yes
Asymmetry measure :disable Passive measure :disable
BMC run info

------------------------------------------------------------------------
Source port :bits0
Port info
Name State Delay-mech Ann-timeout Type Domain
------------------------------------------------------------------------
Ethernet0/2/0 master delay 9 BC 0
Ethernet0/2/3 master pdelay 9 BC 0
Clock source info

Clock Pri1 Pri2 Accuracy Class TimeSrc Signal Switch Direction In-Status
------------------------------------------------------------------------
local 128 128 0x31 187 0xa0 - - - -
bits0 128 128 0x20 6 0x20 1pps on in/- normal
bits1 128 128 0x20 6 0x20 1pps on in/- normal
If the ATN device is in the downstream direction, it must synchronize to the time of the upstream
device through its external time interface. In this case, check the text in bold displayed in the
command output. In this example, the ATN device is expected to synchronize to the BITS0 time
source. Therefore, ensure that the BITS0 source is in normal input state and is correctly
synchronized. If the bold text shows the time source is BITS0 but is not locked by the ATN
device, wait for 5 minutes and then check it again. If the BITS0 clock source is still unlocked,
check whether the clock source is normal. If not, configure a normal clock source for the ATN
device.
Step 3 On the ATN device, run the display ptp-adaptive all command to view the IEEE 1588ACR
time information.
<HUAWEI> system
[HUAWEI] display ptp-adaptive all
Device config info
------------------------------------------------------------------------

Equipment
Ptp adaptive state : Enable Device type : client

Sync mode : Frequency Current state : slave
Packet dscp : 56 Domain value : 0
Announce interval : 11 Announce duration : 80s
Sync interval : 3 Sync duration : 80s
Announce receipt timeout: 8s Acr mode : One-way
Local ip : 81.0.1.21
Ptp port name : GigabitEthernet0/2/2
Remote server info

------------------------------------------------------------------------
Current negotiate server : 2
Ip address Negotiate state
Server1:
Server2: 81.0.1.127 Nego success
If the ATN device is in the downstream direction, it must synchronize to the clock of the upstream
device. In this case, check the text in bold displayed in the command output. In this example,
the ATN device is expected to synchronize to the 1588ACR clock of the upstream device. Check
whether the ATN device has successfully negotiated with the clock servers and is in stable state.
If the state is stable, the ATN device has successfully synchronized to the clock of the upstream
device.
----End

N/A

Equipment
Commissioning Guide 6 Connecting a Device to the NMS
6 Connecting a Device to the NMS
This chapter describes three methods to connect a device to the NMS.
You can connect a device to the NMS using SNMPv1, SNMPv2c, or SNMPv3.
Prerequisite
l The device is running properly.
l An IP address has been configured for the interface connecting the device to the NMS.
l A reachable route exists between the ATN and the NMS.
Data preparation
Table 6-1 lists the data required for connecting the device to the NMS.
Table 6-1 Data required for connecting the ATN to the NMS
Item Data Remarks
SNMP version of the ATN V1/V2C/V3 The value can be v1,

v2c, or v3.
IP address of the NMS 192.167.1.10 None.
Parameters of SNMPv1, l read community name: None.

including SNMP read and Com#access
write community names and l write community name:
the ACL number. Mgr#access
l ACL number: 2000
Parameters of SNMPv2c, l read community name: None.

including SNMP read and Com#access
write community names and l write community name:
the ACL number. Mgr#access
l ACL number: 2001

Equipment
Item Data Remarks
Parameters of SNMPv3, l SNMP group name: NMS None.

including SNMP group and l SNMP user name: John
user names and the ACL
number. l ACL number: 2002
NOTE
SNMPv3 is recommended because it provides more secure functions than other SNMP protocols.
Procedure
l Configure SNMPv1.
1. Configure basic functions of SNMPv1 on the ATN.
# Configure SNMP version.

[HUAWEI] snmp-agent
[HUAWEI] snmp-agent sys-info version v1
# Set the SNMP community name: the read community name of ATN is comaccess
Com#accessand the write community name is Mgr#access. For details, see snmp-
agent community.
[HUAWEI] snmp-agent community read Com#access acl 2000
[HUAWEI] snmp-agent community write Mgr#access acl 2000
2. Configure access control in SNMPv1. For more information, please refer to rule (ACL
view).
[HUAWEI] acl 2000
[HUAWEI-acl-basic-2000] rule permit source 192.167.1.10 0
[HUAWEI-acl-basic-2000] quit
3. Configure trap functions and set the IP address of the trap server to be the IP address
of the NMS, 192.167.1.10.
NOTE
The trap function must be configured so that the NMS can receive the alarms from the device.
[HUAWEI] snmp-agent trap enable

[HUAWEI] snmp-agent target-host trap address udp-domain 192.167.1.10
params securityname Com#access v1 private-netmanager
l Configure SNMPv2c.
1. Configure basic functions of SNMPv2c on the ATN.

[HUAWEI] snmp-agent
[HUAWEI] snmp-agent sys-info version v2c
# Set the SNMP community name: the read community name of ATN is
Com#access and the write community name is Mgr#access. For details, see snmp-
agent community.

Equipment
[HUAWEI] snmp-agent community read Com#access acl 2001

[HUAWEI] snmp-agent community write Mgr#access acl 2001
2. Configure Community-Name-based access control in SNMPv2c. For more

information, see rule (ACL view).
[HUAWEI] acl 2001
of the NMS, 192.167.1.10. For more information, see snmp-agent target-host trap.
NOTE
l Configure SNMPv3.
1. Configure basic functions of SNMPv3 on the ATN. ATN

[HUAWEI] snmp-agent
[HUAWEI] snmp-agent sys-info version v3
2. Configure User-based access control in SNMPv3.
# Configure an SNMP user group, and the user group name is NMS.
[HUAWEI] snmp-agent group v3 NMS
# Configure user information. For example, Add a user named John to the SNMP
group named NMS, with the security level being authentication, the authentication
protocol being HMAC-MD5-96 and the password being hello1234. For more
information, see the command snmp-agent usm-user.
[HUAWEI] snmp-agent usm-user v3 John authentication-mode md5 hello1234
# Configure a basic ACL. For more information, see the command rule (ACL view).
[HUAWEI] acl 2002
# Apply the ACL based on the user. For more information, see the command snmp-
agent usm-user.
[HUAWEI] snmp-agent usm-user v3 John NMS acl 2002
of the NMS, 192.167.1.10. For more information, see the command snmp-agent
target-host trap.
NOTE
----End

Equipment
After the configurations of the ATN and the NMS are complete, you can access the ATN through
the NMS.


Commissioning Guide: ATN 910&910I&910B&950B Multi-Service Access Equipment V200R003C10

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Commissioning Guide: ATN 910&910I&910B&950B Multi-Service Access Equipment V200R003C10

Загружено:

Авторское право:

Доступные форматы

ATN 910&910I&910B&950B Multi-Service Access

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2014-04-30) Huawei Proprietary and Confidential i

About This Document

This document describes the commissioning flow and method.

The usage precautions are as follows:

Product Name Version

l ATN 910 V200R003C10

Issue 02 (2014-04-30) Huawei Proprietary and Confidential ii

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 02 (2014-04-30) Huawei Proprietary and Confidential iii

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

Boldface Buttons, menus, parameters, tabs, window, and dialog titles

> Multi-level menus are in boldface and separated by the ">"

Changes in Issue 02 (2014-04-30)

Known bugs are fixed.

Changes in Issue 01 (2014-01-31)

Issue 02 (2014-04-30) Huawei Proprietary and Confidential iv

About This Document.....................................................................................................................ii

3 Checking the Hardware..............................................................................................................22

4 Commissioning the Link Layer................................................................................................31

5 Commissioning Services and Protocols..................................................................................61

Issue 02 (2014-04-30) Huawei Proprietary and Confidential v

5.5 Commissioning MPLS LDP.........................................................................................................................................81

6 Connecting a Device to the NMS...........................................................................................116

Issue 02 (2014-04-30) Huawei Proprietary and Confidential vi

Figure 1-1 shows the commissioning flow.

Figure 1-1 Commissioning flow

Table 1-1 describes commissioning procedures.

Table 1-1 Commissioning procedures

Commissioning Procedure Description

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 1

Commissioning Procedure Description

Checking the Hardware Describes how to check the power supply,

Commissioning Services and Protocols Describes how to commission services and

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 2

2 Logging In to the ATN

About This Chapter

2.1 Logging In to the ATN by Using SSH

2.2 Logging In to the ATN by Using Telnet

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 3

2.3 Logging In to the ATN by Using the Console Interface

2.4 Clearing the Password

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 4

2.1 Logging In to the ATN by Using SSH

SSH Client SSH Server

Step 3 Create an RSA or DSA key pair.

Issue 02 (2014-04-30) Huawei Proprietary and Confidential 5

Table 2-1 Configuring an authentication mode for the SSH user

Operation Command Description

Configure 1. Run the ssh user user-name If local or HuaWei Terminal