ATN_910_and_910I_and_910B_and_950B_Multi.pdf

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 mentioned in this document are the property of of their respective respective holders. 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 document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, 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 recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd. Address:

Huawei Industrial Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China

Website:

http://www.huawei.com

Email:

[email protected]

Issue 02 (2014-04-30)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

i

ATN 910&910I&910B&950B Multi-Service Access 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 l

ATN 910

l

ATN 910I

l

ATN 910B

l

ATN 950B

Version V200R003C10

Intended Audience This document is intended for: Issue 02 (2014-04-30)


ii

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

About This Document

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. Indicates a potentially hazardous situation which, if not avoided, may result in minor or moderate injury. Indicates a potentially hazardous situation which, if not 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 i tem 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)


iii


About This Document

Convention

Description

[ x | y | ... ] *

Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected.

GUI Conventions Convention

Description

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)


iv


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)


v


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)


vi


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

Issue 02 (2014-04-30)

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.


1


Issue 02 (2014-04-30)

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.


2


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 maintena nce. 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 Issue 02 (2014-04-30)


3



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.

Issue 02 (2014-04-30)


4



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 i nterface 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 k ey pair. l

Issue 02 (2014-04-30)

Run the rsa local-key-pair create command to create a local RSA key pair. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

5



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

Issue 02 (2014-04-30)

Operation

Command

Description

Configure Password Authentication

1. Run the ssh user user-name authentication-type password command

If local or HuaWei Terminal Access Controller Access Control 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 password cipher password command to configure the user name and the password for the local user.

The user name must be the same to the SSH user.

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

-


By default, the administrators are all in the domain default_admin.

6



Operation

Command

Description

Configure RSA authentication

1. Run the ssh user user-name authentication-type rsa command to configure RSA authentication.

-

2. Run the rsa peer-public-key keyname [ encoding-type { der | openssh | pem } ] command to configure an encoding format for an RSA public key and enter the RSA public key view.

Huawei data communications devices support only the DER format for RSA keys before VRP V500R012C01 version. If you use an RSA key in non-DER format, use a third-party tool to convert the key into a key in DER format.

The default encoding format is distinguished encoding rules (DER) for an RSA public key.

In addition to DER, RSA keys need to support the privacyenhanced 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 key.

l

l

Issue 02 (2014-04-30)


In the public key edit view, 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. After entering the public key edit view, paste the RSA public key generated on the client to the server.

7


Operation

Configure DSA authentication


Command

Description

5. Run the public-key-code end command to exit from the public key edit view.

-

6. Run the peer-public-key end command to return to the system view.

l

Running the peer-public-key end command generates a key only after a valid hex-data complying with the public key 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.

-

1. Run the ssh user user-name 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.

Issue 02 (2014-04-30)


-

8


Operation


Command

Description

4. Enter hex-data to edit the public key.

l

l

In the public key edit view, 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. 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 command to return to the system view.

l

Running the peer-public-key end command generates a key only after a valid hex-data complying with the public key 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.

Issue 02 (2014-04-30)

As shown in Figure 2-2, set the IP address of the ATN to 129.0.0.1 and the login protocol to SSH. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

9



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.

Issue 02 (2014-04-30)

Enter the user name root and the password Changeme_123 .


10



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. display ssh server status SSH version SSH connection timeout SSH server key generating interval SSH Authentication retries SFTP server Stelnet server

:1.99 :60 seconds :0 hours :3 times : Disable : 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. 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

Issue 02 (2014-04-30)


11



[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-keypair 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 [HUAWEI] ssh [HUAWEI] ssh [HUAWEI] ssh

user user user user

[email protected] [email protected] authentication-type all [email protected] service-type all [email protected] 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 [email protected] 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 [email protected] 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. display user-interface maximum-vty Maximum of VTY user:5 display users User-Intf Delay Type Network Address 34 VTY 0 03:31:35 TEL 10.138.81.138 Username : Unspecified

Issue 02 (2014-04-30)


AuthenStatus pass

AuthorcmdFlag no

12

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide 35 VTY 1 03:51:58 Username : Unspecified 36 VTY 2 00:10:14 Username : Unspecified 37 VTY 3 02:31:58 Username : Unspecified + 39 VTY 4 00:00:00 Username : Unspecified

2 Logging In to the ATN TEL

10.137.128.126

pass

no

TEL

10.138.81.184

pass

no

TEL

10.138.80.199

pass

no

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. system-view [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. 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. system-view [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. system-view [HUAWEI] undo ssh server compatible-ssh1x enable

9.

Enable first-time authentication on the SSH client. system-view [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.

Issue 02 (2014-04-30)


13



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 i nterface 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. 1.


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


2.

Run the user-interface maximum-vty number command to set the maximum number of login users that can use VTY user i nterfaces on the ATN.

Step 3 Configure a user authentication mode. One of them can be selected as needed. NOTE

l

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.

Configure password authentication.

1.


2.


3.

Run the set authentication password [ cipher password ] command to set the password used in authentication.

l

Configure AAA authentication.

1.


2.


Issue 02 (2014-04-30)


14



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

Commissioning Results 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 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. display user-interface maximum-vty Maximum of VTY user:5 display users User-Intf Delay Type Network Address 34 VTY 0 03:31:35 TEL 10.138.81.138 Username : Unspecified 35 VTY 1 03:51:58 TEL 10.137.128.126 Username : Unspecified 36 VTY 2 00:10:14 TEL 10.138.81.184 Username : Unspecified 37 VTY 3 02:31:58 TEL 10.138.80.199 Username : Unspecified + 38 VTY 4 00:00:00 TEL 10.138.78.80 Username : Unspecified

AuthenStatus pass

AuthorcmdFlag no

pass

no

pass

no

pass

no

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 Issue 02 (2014-04-30)


15



that can use VTY user interfaces to 15, and you should configure authentication modes for newly added VTY user interfaces. system-view [HUAWEI] user-interface maximum-vty 15 [HUAWEI] user-interface vty 5 14 [HUAWEI-ui-vty5-14] authentication-mode aaa

3.

Check that an ACL is configured in the VTY user interface view. [HUAWEI] user-interface vty 0 4 [HUAWEI-ui-vty0-4] display this user-interface vty 0 4

acl 2000 inbound authentication-mode aaa user privilege level 3 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. [HUAWEI] user-interface vty 0 4 [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 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 netmanager) 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.

Issue 02 (2014-04-30)


16



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: l


l


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 t o 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


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 f ollowing 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. Issue 02 (2014-04-30)


17



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

Issue 02 (2014-04-30)


18



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)

Issue 02 (2014-04-30)


19



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 relate d 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

Issue 02 (2014-04-30)


20



Follow-up Procedure Log in to the device.

Issue 02 (2014-04-30)


21


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.

Issue 02 (2014-04-30)


22



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. display version Huawei Versatile Routing Platform Software

VRP (R) softwa re, Version 5.150 (ATN910 V200R00 3C10) 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. display startup MainBoard: Configured startup system software: Startup system software: Next startup system software: Startup saved-configuration file: Next startup saved-configuration file: Startup paf file: Next startup paf file: Startup license file: Next startup license file: Startup patch package: Next startup patch package:

cfcard:/ V200R003C10.cc cfcard:/ V200R003C10.cc cfcard:/ V200R003C10.cc cfcard:/ vrpcfg.zip cfcard:/ vrpcfg.zip cfcard:/paf-V200R003C10.txt cfcard:/paf-V200R003C10.txt cfcard:/license-V200R003C10.txt cfcard:/license-V200R003C10.txt cfcard:/patch.bat cfcard:/patch.bat

If the names of system software and configuration files, displayed in boldface in t he 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.

Issue 02 (2014-04-30)


23



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.


Procedure Step 1 Run the display health command to view the health status of the ATN. ATN 910/ATN 910I/ATN 910B: display health Slot CPU Usage Memory Usage(Used/Total) -------------------------------------------------------- 2 MPU(Master) 9% 21% 396MB/1823MB

ATN 950B: 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.


Issue 02 (2014-04-30)


24



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

ATN 910/ATN 910I/ATN 910B: display device ATN910's Device status: Slot # Type Online Register Status Primary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2 CXP Present NA Normal Master 3 PIC Present Normal NA Registered 5 PWR Present Abnormal NA Registered 6 FAN Present Normal NA Registered

Pay attention to the Register and Status fields in the displayed information. l

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. 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 i s powered on is called the start-up time. Wait until the start-up time expires. If the board is st ill unregistered when the start-up time expires, go to next step.

2. Issue 02 (2014-04-30)

Check that the board type is supported by the system software. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

25



Supported board types vary with system software versions. For the types of boards t hat 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


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.


Procedure Step 1 Run the display fan command to check the fan status. ATN 950B: display fan SlotID : 11

Present : Registered: Status : FanSpeed : : : : : : :

YES YES MANUAL [No.]Speed [1] 95% [2] 95% [3] 95% [4] 95% [5] 95% [6] 95%

ATN 910/ATN 910I/ATN 910B: Issue 02 (2014-04-30)


26



display fan SlotID : 6

Present : Registered: Status : FanSpeed : : : :

YES YES AUTO [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

Commissioning Result 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.


Procedure Step 1 Run the display power command to check the power status. ATN 910/ATN 910I/ATN 910B: display power No Present mode State Num ------------------------------------------------------------------------------5 Yes DC Normal 1

ATN 950B: 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

Commissioning Result The displayed information may be different in real-world situations. For more information, see display power. Issue 02 (2014-04-30)


27



3.6 Checking System Time This section describes how to verify whether the system time meets the system requirements.


Procedure Step 1 Run the display clock command to view system time. 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.


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. Issue 02 (2014-04-30)


28

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide 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 Eth-Trunk0 up up 3% GigabitEthernet0/2/0 up up 50% GigabitEthernet0/2/1 *down down 40% GigabitEthernet0/2/2 up up 0% GigabitEthernet0/2/3.1 up up 0%


OutUti 7% 60% 30% 0% 0%

inErrors 12 23 0 0 0

outErrors 0 125 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:

Issue 02 (2014-04-30)

l


l

Configuration files, log files, and alarm files of the ATN Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

29



3.8 Checking Alarm Information This section describes how to verify alarms and faults about the ATN.


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

Issue 02 (2014-04-30)


30


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.

Issue 02 (2014-04-30)


31



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 .

l


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: 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 Trunk GigabitEthernet0/2/0 enable half up -GigabitEthernet0/2/1 up disable full -GigabitEthernet0/2/2 up disable full -GigabitEthernet0/2/3 up disable full -GigabitEthernet0/2/4 disable full up -GigabitEthernet0/2/5 up disable full --

Bandwidth

InUti

OutUti

100M

0%

0%

1000M

0%

0%

1000M

0%

0%

1000M

0%

0%

1000M

0.01%

0.01%

1000M

0%

0%

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: 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: 13 10nm, Transmissio n 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

Issue 02 (2014-04-30)


32



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: Unicast: 36269109535 packets, Multicast: 541563 packets Broadcast: 106 packets, JumboOctets: 0 packets 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: 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 Reply from 192.168.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 192.168.1.2: bytes=56 Sequence=3 ttl=255 time=1 ms Reply from 192.168.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 192.168.1.2: bytes=56 Sequence=5 ttl=255 time=113 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. Issue 02 (2014-04-30)


33



– 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. l

If the fault persists after the preceding operations are complete, contact Huawei technical support personnel.

If an Ethernet interface cannot be pinged, perform the following operations: 1.

Check that the local end is correctly connected to the peer end. Obser ve 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 l


l


Procedure Step 1 Run the display controller e1 command to check the status of a CE1 interface. For example: 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

Issue 02 (2014-04-30)


34



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: 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 Current system time: 2011-01-21 17:45:40 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 Input bandwidth utilization : 0.00% Output bandwidth utilization : 0.00%

As shown by the characters displayed in boldface, the physical status and li nk 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: 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 Reply from 192.168.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 192.168.1.2: bytes=56 Sequence=3 ttl=255 time=1 ms Reply from 192.168.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 192.168.1.2: bytes=56 Sequence=5 ttl=255 time=113 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 If E-carrier interfaces on both ends of a link cannot communicate with each other after the interfaces are configured, perform the following operations: Issue 02 (2014-04-30)


35


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:

b.

l

Fiber is properly connected to the local interface and the i ndicator 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.

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.

3.

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.

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.

Issue 02 (2014-04-30)


36



Prerequisite l


l


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. 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: 13 10nm, Transmissio n 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 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: Unicast: 36269109535 packets, Multicast: 541563 packets Broadcast: 106 packets, JumboOctets: 0 packets 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%

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 Issue 02 (2014-04-30)


37



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 2.2.2.2/3 1.1.1.1/3 2 2 192.168.1.1 / 24 T1 0/3/0 Console

PC

Issue 02 (2014-04-30)

T1 1/0/0 192.168.1.2 / 24

ATNA

network

POS3/0/0 192.167.1.10 / 24

CX600B


38



Procedure Step 1 On the ATN device, run the display controller t1 command to check the CT1 interface status. 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 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: 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. [HUAWEI-T1 0/3/0] display this interface T1 0/3/0 current state : DOWN 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: LOF

Issue 02 (2014-04-30)

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

39



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. [HUAWEI-T1 0/3/0] display this interface T1 0/3/0 current state : DOWN 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: 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

Issue 02 (2014-04-30)


40



Loopback Mode

Description

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 i nterface to the local T1 interface is normal. If the physical state of t he 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 As shown in Figure 4-3, 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 DSLAM is located.

Issue 02 (2014-04-30)


41



Figure 4-3 Typical networking diagram for XDSL interface commissioning

2.2.2.2/3 1.1.1.1/3 2 2 192.168.1.1 / 24 DSL0/4/0 Console

PC

ATNA

network

DSL0/3/0 GE0/3/0 192.168.1.2 / 24 192.167.1.10 / 24 DSLAM

Procedure Step 1 On the ATN device, run the display interface brief command to view the status of t he dsl-group and VE interfaces on the ATN device. 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 Dsl-group0/4/0 up up Virtual-Ethernet0/4/0 up down 0 Virtual-Ethernet0/4/0.1 up up 0 Virtual-Ethernet0/4/0.2 up up 0 Virtual-Ethernet0/4/0.6 up up 0 Virtual-Ethernet0/4/0.7 up down 0 Virtual-Ethernet0/4/0.11 up up 0 Virtual-Ethernet0/4/1 up down Xdsl0/4/0 up up 0 Xdsl0/4/1 up up 0 Xdsl0/4/2 up up

Issue 02 (2014-04-30)

InUti OutUti 0% 0% 0% 0%

inErrors 0 0

0%

0%

0

0%

0%

0

0%

0%

0

0%

0%

0

0%

0%

0

0% 0%

0% 0%

0

0%

0%

0

0%

0%

0


0

outErrors 0

0

42

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide 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

Handling Common Faults 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 As shown in Figure 4-4, 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-4 Typical networking diagram for ATM interface commissioning Legacy 2G BTS BSC/RNC

Voice and Data Over TDM

CX600B

n * E1 n * E1

ATNA

CBSC

3G BTS EVDO-R0/REV A/REV B

Issue 02 (2014-04-30)


43



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 li nk 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

Issue 02 (2014-04-30)


44



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 :

Issue 02 (2014-04-30)

0%


45



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 local VC label : 32 remote VC label 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 local VCCV : alert ttl lsp-ping bfd remote VCCV : alert ttl lsp-ping bfd local control word : disable remote control word tunnel policy name : tp31 PW template name : 1

Issue 02 (2014-04-30)


: 0 : 28

: 28

: disable

46

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide primary or secondary load balance type Access-port Switchover Flag VC tunnel/token info NO.0 TNL type Backup TNL type create time up time last change time VC last up time VC total up time CKey NKey PW redundancy mode AdminPw interface AdminPw link state Diffserv Mode Service Class Color DomainId Domain Name

4 Commissioning the Link Layer : : : : : : : : : : : : : : : : : : : : : :

primary flow false false 1 tunnels/tokens cr lsp, TNL ID : 0x3 lsp , TNL ID : 0x0 0 days, 0 hours, 0 minutes, 0 days, 0 hours, 0 minutes, 0 days, 0 hours, 0 minutes, 2012/04/28 16:46:06 0 days, 0 hours, 0 minutes, 9 1 frr --pipe ef green ---

11 seconds 11 seconds 11 seconds 11 seconds

----End

Handling Common Faults 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:

2.

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.

Cause 2: The PW or tunnel carrying the ATM service is down. Handling procedure:

Issue 02 (2014-04-30)


47


3.


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.

Cause 3: The MAP PVC or MAP PVP on the ATN device is inconsistent with that on the CX600. Handling procedure:

4.

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 t he 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 fault handling procedure.

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:

Issue 02 (2014-04-30)

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

48


d.

3.


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.

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 subinterface 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 Hardware commissioning has been completed, the ATN device to be commissioned is running properly, the E1 cables on the AC sides for carrying TDM services are correctly connected, and network-side cables are connected correctly.

Context As shown in Figure 4-5, 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.

Issue 02 (2014-04-30)


49



Figure 4-5 Typical networking diagram for TDM interface commissioning Legacy 2G BTS BSC/RNC


CX600B

n * E1 n * E1

ATNA Data Over ML-PPP/ATM

CBSC


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. [HUAWEI-Serial0/2/2:1] display this # interface Serial0/2/2:1 link-protocol tdm mpls l2vc 2.2.2.2 pw-template 1 101 # return

On the CX600 device, use the same way t o 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

:

AC status

:

up

up

Issue 02 (2014-04-30)


50



VC state

:

Label state

:

Token state

:

VC ID

:

VC type

: CESoPSN basic

up

0

0

101

mode destination 2.2.2.2

:

local group ID

: 0

remote group ID

:

local VC label

: 16

remote VC label

:

local TDM Encap Num

: 8

remote TDM Encap Num :

jitter-buffer

:

idle-code

:

0 20 8 4

ff local rtp-header disable local bit-rate 31 local AC OAM State up local PSN OAM State

: disable

remote rtp-header

:

: 31

remote bit-rate

:

:

:

up local forwarding state : forwarding local status code

:

remote AC OAM state

:

remote PSN OAM state

:

0x0

up

up remote forwarding state: forwarding remote status code

:

ignore standby state

:

0x0

no BFD for PW unavailable

Issue 02 (2014-04-30)

:


51



VCCV State

:

manual fault

: not

active state

:

forwarding entry

:

OAM Protocol

:

OAM Status

:

OAM Fault Type

:

PW APS ID

:

PW APS Status

:

TTL Value

:

link state

:

local VC MTU

: --

local VCCV

: alert ttl lsp-ping

remote VCCV

: alert ttl lsp-ping

up

set

active

exist

--

--

--

0

--

1

up remote VC MTU

:

-bfd bfd local control word disable tunnel policy name tp31 PW template name

: disable

remote control word

:

:

:

1 primary or secondary primary

:

load balance type

:

Access-port

:

Switchover Flag

:

VC tunnel/token info

: 1 tunnels/

flow

false

false

tokens NO.0

TNL type

: cr lsp, TNL ID :

0x3 Backup TNL type

: lsp

, TNL ID :

0x0 create time

Issue 02 (2014-04-30)

: 0 days, 4 hours, 42 minutes, 2


52

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide seconds up time seconds last change time seconds VC last up time 14:44:27 VC total up time seconds CKey 2


: 0 days, 0 hours, 3 minutes, 59 : 0 days, 0 hours, 3 minutes, 59 : 2012/04/28 : 0 days, 0 hours, 3 minutes, 59 :

NKey

:

PW redundancy mode

:

AdminPw interface

:

AdminPw link state

:

Diffserv Mode

:

Service Class

:

Color

:

DomainId

:

Domain Name

: --

1

frr

--

--

pipe

ef

green

--

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

Handling Common Faults The PW profile parameters of the ATN device are inconsistent with those of the CX600.

1.

Handling procedure:

a.

b.

Issue 02 (2014-04-30)

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


53

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide Rtp-Header VCCV Capability Behavior Name Total PW

4 Commissioning the Link Layer : Disable : alert ttl lsp-ping bfd : -: 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. [HUAWEI-Serial0/2/2:1] display this # interface Serial0/2/2:1 link-protocol tdm mpls l2vc 2.2.2.2 pw-template 1 101 # return

For the E1 interfaces on the ATN device and CX600, the channelized mode or the number of bound timeslots differs.

1.

Handling procedure:

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

Issue 02 (2014-04-30)


54



Token state : 0 VC ID : 101 VC type : SAT E1 over Packet destination : 2.2.2.2 local VC label : 16 remote VC label : 0 control word : disable TDM encapsulation number : 8 jitter-buffer : 4 idle-code : ff rtp-header : disable forwarding entry : not exist local group ID : 0 manual fault : not set active state : inactive link state : down local VC MTU : 2000 remote VC MTU : 0 tunnel policy name : -traffic behavior name: -PW template name : 1 primary or secondary : primary load balance type : flow Access-port : false create time : 0 days, 1 hours, 9 minutes, 32 seconds up time : 0 days, 0 hours, 0 minutes, 0 seconds last change time : 0 days, 1 hours, 9 minutes, 32 seconds VC last up time : 0000/00/00 00:00:00 VC total up time : 0 days, 0 hours, 0 minutes, 0 seconds CKey : 4 NKey : 3 AdminPw interface : -AdminPw link state : -Diffserv Mode : pipe Service Class : ef Color : green DomainId : -Domain Name : --

2.

Issue 02 (2014-04-30)

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.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

55



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

1.

Handling procedure:

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 Hardware commissioning has been completed, the ATN device to be commissioned is running properly, and the E1 cables on the AC sides of the PPP link are correctly connected.

Context As shown in Figure 4-6, 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-6 Typical networking diagram for MP interface commissioning Legacy 2G BTS BSC/RNC


CX600B

n * E1 n * E1

ATNA Data Over ML-PPP/ATM

CBSC


Issue 02 (2014-04-30)


56



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 # interface Serial0/2/0:1 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 Line protocol current state : UP Last line protocol up time : 2012-04-28 14:44:33 Description:HUAWEI, Mp-group0/2/1 Interface Route Port,The Maximum Transmit Unit is 1500 Internet Address is 10.1.2.1/24 Link layer protocol is PPP

LCP opened, MP opened, IPCP opened, MPLSCP opened Physical is MP, baudrate is 1984000 bps Current system time: 2012-04-28 15:12:06 Statistics last cleared:never 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

Issue 02 (2014-04-30)


57



Input bandwidth utilization : 0.02% Output bandwidth utilization : 0.03%

----End

Handling Common Faults 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. [HUAWEI-Serial0/2/0:1] display this interface Serial0/2/0:1 current state : DOWN

b.

2.

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.

Cause 2: Key parameters are inconsistent for the ATN device and CX600. Handling procedure:

a.

In the interface view, run the display this interface command to check the physical state of the serial interface. [HUAWEI-Serial0/2/1:0] display this 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

Link layer protocol is PPP LCP initial CRC: CRC-32

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 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 fault handling procedure.

Cause 3: A loopback has been performed for the interface. Handling procedure:

a.

In the interface view, run the display this interface command to check the physical state of the serial interface. [HUAWEI-Serial0/2/0:1] display this 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

Issue 02 (2014-04-30)


58



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 Line protocol current state : UP Last line protocol up time : 2011-08-10 10:37:33 Description:HUAWEI, Mp-group0/2/1 Interface Route Port,The Maximum Transmit Unit is 1500 Internet Address is 192.168.1.2/24 Link layer protocol is PPP LCP opened, MP opened

MP threshold-lea st is 6, MP bind ing 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.

2.

Cause 2: The IP address of the MP group is incorrect.

a.

Issue 02 (2014-04-30)

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.

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

59


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 Serial0/2/2:2 physical UP,protocol UP Serial0/2/3:2 physical UP,protocol UP Serial0/2/4:1 physical UP,protocol UP Serial0/2/5:1 physical UP,protocol UP Serial0/2/6:3 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.

Issue 02 (2014-04-30)

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.


60


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 IGP （Static Route、OSPF、ISIS）

Commissioning IBGP

Commissioning MPLS LDP、MPLS TE Commissioning VPN （L3VPN、L2VPN）

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 Issue 02 (2014-04-30)


61



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.

Issue 02 (2014-04-30)


62



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 t he network connected to CX600 B. Figure 5-2 Typical networking for commissioning static routes 1.1.1.1/32

192.168.1.1 / 24 GE0/2/0

Console PC

2.2.2.2/32 network

GE1/0/0 POS3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

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. 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 127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0 127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0 127.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0

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. display ip routing-table protocol static Route Flags: R - relay, D - download to fib -------------------------------------------------------------------------Public routing table : Static Destinations : 1 Routes : 1 Configured Routes : 1 Static routing table status :

Issue 02 (2014-04-30)


----

63



Destinations : 1 Routes : 1 Destination/Mask Proto Pre Cost Flags 192.167.1.0/24 Static 60 0 RD GigabitEthernet0/2/0 Static routing table status : Destinations : 0 Routes : 0

NextHop 192.168.1.2

Interface

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. ping 192.167.1.1 0 PING 192.167.1.10: 56 data Reply from 192.167.1.10: Reply from 192.167.1.10: Reply from 192.167.1.10: Reply from 192.167.1.10: Reply from 192.167.1.10:

bytes, press CTRL_C bytes=56 Sequence=1 bytes=56 Sequence=2 bytes=56 Sequence=3 bytes=56 Sequence=4 bytes=56 Sequence=5

to break ttl=254 time=60 ttl=254 time=65 ttl=254 time=36 ttl=254 time=93 ttl=254 time=23

ms ms ms ms ms

--- 192.167.1.10 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 23/55/93 ms

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.

Issue 02 (2014-04-30)

If the fault persists, collect the following information and contact Huawei technical support personnel. l


l

Configuration files, log files, and alarm files of the devices


64



5.2 Commissioning OSPF Routes This section describes how to commission OSPF routes.

Prerequisite l


l


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

Console

2.2.2.2/32

192.168.1.1 / 24 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 ospf peer command on the commissioning device to view its OSPF neighbor information. 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: display ospf routing OSPF Process 1 with Router ID 1.1.1.1

Issue 02 (2014-04-30)


65



Routing Tables Routing for Network

Destination Cost Type NextHop 192.168.1.0/24 1 transit 192.168.1.1 2.2.2.2/32 1 Stub 192.168.1.2 192.167.1.0/24 2 Stub 192.168.1.2 Total Nets: 3 : 0 Intra Area: 3 Inter Area: 0 ASE: 0 NSSA

AdvRouter 1.1.1.1 2.2.2.2 2.2.2.2

Area 0.0.0.0 0.0.0.0 0.0.0.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: display ospf routing OSPF Process 1 with Router ID 1.1.1.1 Routing Tables Routing for Network Destination Cost 192.168.1.0/24 1 2.2.2.2/32 1 192.167.1.0/24 2 Routing for ASEs Destination 190.120.0.0/16 200.0.0.0/24

Type transit Stub Inter-area

Cost 3 3

NextHop 192.168.1.1 192.168.1.2 192.168.1.2

Type Type1 Type1

Tag 1 1

AdvRouter 1.1.1.1 2.2.2.2 2.2.2.2

Area 0.0.0.0 0.0.0.0 0.0.0.0

NextHop 192.168.1.2 192.168.1.2

AdvRouter 3.3.3.3 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 intraarea 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. display ospf interface OSPF Process 1 with Router ID 1.1.1.1 Interfaces Area: 0.0.0.0 IP Address 1.1.1.1 192.168.1.1

(MPLS TE not enabled) Type State Cost P2P P-2-P 0 Broadcast DR 1

Pri 1 1

DR 0.0.0.0 192.168.1.1

BDR 0.0.0.0 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. 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

Issue 02 (2014-04-30)


66



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. display ospf error OSPF Process 1 with Router ID 1.1.1.1 OSPF error statistics General packet errors: 0 : IP: received my own packet 0 : Bad version 0 : Bad area id 0 : Bad virtual link 0 : Bad authentication key 0 : Packet size > ip length 0 : Interface down

0 0 0 0 0 0 0

: : : : : : :

Bad packet Bad checksum Drop on unnumbered interface Bad authentication type Packet too small Transmit error Unknown neighbor

HELLO packet errors: 0 : Netmask mismatch 0 : Dead timer mismatch 0 : Router id confusion 0 : NBMA neighbor unknown

0 0 0 0

: : : :

Hello timer mismatch Extern option mismatch Virtual neighbor unknown Invalid Source Address

0 0

: Router id confusion : Unknown LSA type

0

: Unknown LSA type

LS REQ packet errors: 0 : Neighbor state low 0 : Bad request

0

: Empty request

LS UPD packet errors: 0 : Neighbor state low 0 : LSA checksum bad 0 : Unknown LSA type

0 0

: Newer self-generate LSA : Received less recent LSA

Opaque errors: 0 : 9-out of flooding scope 0 : 11-out of flooding scope type

0 0

: 10-out of flooding scope Unkown TLV

DD packet errors: 0 : Neighbor state low 0 : Extern option mismatch 0 : MTU option mismatch LS ACK packet errors: 0 : Neighbor state low

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 wrong period LSAs Configuration errors: 0 : Tunnel cost mistake

0

: Number of policy failed LSAs

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. ping 192.167.1.1 0 PING 192.167.1.10: 56 data bytes, press CTRL_C to break

Issue 02 (2014-04-30)


67

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

from from from from from

192.167.1.10: 192.167.1.10: 192.167.1.10: 192.167.1.10: 192.167.1.10:

5 Commissioning Services and Protocols bytes=56 bytes=56 bytes=56 bytes=56 bytes=56

Sequence=1 Sequence=2 Sequence=3 Sequence=4 Sequence=5

ttl=255 ttl=255 ttl=255 ttl=255 ttl=255

time=3 time=3 time=2 time=3 time=3

ms ms ms ms ms


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 t he 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.

Issue 02 (2014-04-30)


68


2.


In other cases, go to Step 9.

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. display ospf interface OSPF Process 1 with Router ID 1.1.1.1 Interfaces Area: 0.0.0.0 IP Address

Type

(MPLS TE not enabled) Cost State

192.168.1.1

Broadcast

Pri

DR

1

192.168.1.1

BDR

DR

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. display ospf cumulative OSPF Process 1 with Router ID 1.1.1.1 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

Issue 02 (2014-04-30)


69



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

5.

6.

If the OSPF status of the interface is normal (for example, DR, BDR, DR Other, or P2P), go to Step 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.

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.

7.

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.

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. display ospf interface OSPF Process 100 with Router ID 1.1.1.41 Interfaces Area: 0.0.0.0 (MPLS TE not enabled) IP Address Type State Cost BDR 192.168.1.1 Broadcast DR 1 0.0.0.0

8.

Pri

DR

1

192.168.1.1

Check that OSPF configurations on both ends are correct. a.

Check whether the OSPF router IDs of the two ends conflict. display ospf brief OSPF Process 1 with Router ID 1.1.1.1 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. display ospf interface OSPF Process 1 with Router ID 111.1.1.1 Interfaces (MPLS TE not enabled) Area: 0.0.0.0 IP Address Type State Cost BDR 192.168.1.1 Broadcast DR 1 0.0.0.0

c.

Pri

DR

1

192.168.1.1

Check whether other OSPF configurations on both ends are consistent. Run the display ospf error command every 30s for 3 times. display ospf error OSPF Process 1 with Router ID 1.1.1.1

Issue 02 (2014-04-30)


70

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide OSPF error statistics General packet errors: 0 : IP: received my own packet 0 : Bad version 0 : Bad area id interface 0 : Bad virtual link 0 : Bad authentication key 0 : Packet size > ip length 0 : Interface down HELLO packet errors: 0 : Netmask mismatch 0 : Dead timer mismatch 0 : Router id confusion 0 : NBMA neighbor unknown


0 0 0

: Bad packet : Bad checksum : Drop on unnumbered

0 0 0 0

: : : :

Packet too small Transmit error Unknown neighbor

0 0 0 0

: : : :

Hello timer mismatch Extern option mismatch Virtual neighbor unknown Invalid Source Address

Bad authentication type

l

Check Check the Bad authenticat authentication ion 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 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 t he 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. 9.

Collect Collect the following following informatio information n and contact contact Huawei Huawei technical technical support support personn personnel: el: l


l


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

Prerequisites l


l


Context On the network shown in Figure 5-4, IS-IS is configured on the network to ensure successful communication between the commissioning device and the network connected to CX600 B. Issue 02 (2014-04-30)


71



Figure 5-4 Typical networking for commissioning IS-IS routes 1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE0/2/0

network

GE1/0/0 POS3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

ATNA

CX600B

Procedure Step 1 Run the display isis peer command on the commissioning device to view its IS-IS neighbor information. 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. display isis interface Interface information for ISIS(2) --------------------------------Interface Id MTU Type DIS IPV4.State 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 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. 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, nexthop addresses, and routing information flags are correct. current-configuration command on the commissioning device to check the Step 4 Run the display current-configuration

configurations that have taken effect. display current-configuration # isis 1

Issue 02 (2014-04-30)


72



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. ping 192.167.1.1 0 PING 192.167.1.10: 56 data bytes, press CTRL_C Reply from 192.167.1.10: bytes=56 Sequence=1 Reply from 192.167.1.10: bytes=56 Sequence=2 Reply from 192.167.1.10: bytes=56 Sequence=3 Reply from 192.167.1.10: bytes=56 Sequence=4 Reply from 192.167.1.10: bytes=56 Sequence=5

to break ttl=255 time=3 ttl=255 time=2 ttl=255 time=2 ttl=255 time=2 ttl=255 time=2

ms ms ms ms ms


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 Check that that IS-IS IS-IS can can rece receive ive and and send send Hello Hello pack packets ets prop properl erly. y. 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 statistics based on on the levels levels of established established neighbor neighbor relationships. relationships. On a P2P P2P interface, IS-IS IS-IS Hello packets have no IS-IS levels and are recorded as L2 IIH packets.

Issue 02 (2014-04-30)

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: Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

73



– 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

l

3.

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." If the interface status is Up, go to next step.

Check the status of IS-IS interfaces. Run the display isis interface command to check the status of the interfaces enabled with IS-IS.

4.

5.

l

If the interface status is Mtu:Dn/Lnk:Up/IP:Up , run the display currentconfiguration 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.

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.

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.

6.

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.

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

Issue 02 (2014-04-30)


74


7.


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

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.

8.

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.

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.

9.

l

If the authentication modes configured on both are different, run t he isis authenticationmode 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.

Collect the following information and contact Huawei technical support personnel. l


l


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

Prerequisites l


l


Issue 02 (2014-04-30)


75



Context On the network shown in Figure 5-5, IBGP is configured on the network to ensure successful communication between the commissioning device and the network connected to CX600 B. Figure 5-5 Typical networking for commissioning IBGP routes 1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE0/2/0

network

GE1/0/0 POS3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

ATNA

CX600B AS100

Procedure Step 1 Run the display bgp peer command to view IBGP peer information. display BGP local router Local AS number Total number of Peer V PrefRcv 4 2.2.2.2

bgp peer ID : 1.1.1.1 : 100 peers : 1 AS MsgRcvd 100

MsgSent

274

7

Peers in established state : 1 OutQ Up/Down State 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: 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 Issue 02 (2014-04-30)


76



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: display bgp routing-table 192.167.1.0

BGP local router ID : 1.1.1.1 Local AS number : 100 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 BGP routing table entry information of 192.167.1.0/24: From: 2.2.2.2 (2.2.2.2) Route Duration: 00h08m36s Relay IP Nexthop: 192.168.1.2 Relay IP Out-Interface: GigabitEthernet0/2/0 Original nexthop: 2.2.2.2 Qos information : 0x0 AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, 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: display bgp routing-table community 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 *>i 192.167.1.0 2.2.2.2

l

MED 0

LocPrf 100

PrefVal Community 0 no-export

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. display bgp routing-table 192.167.1.0

BGP local router ID : 1.1.1.1 Local AS number : 100 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.02) Route Duration: 01h22m50s Direct Out-interface: GigabitEthernet0/2/0 Original nexthop: 192.168.1.2 Qos information : 0x0

Issue 02 (2014-04-30)


77



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

BGP routing table entry information of 192.167.1.0/24: From: 2.2.2.2 (2.2.2.2) Route Duration: 00h08m36s Relay IP Nexthop: 192.168.1.2 Relay IP Out-Interface: GigabitEthernet0/2/0 Original nexthop: 2.2.2.2 Qos information : 0x0 AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre 255, not preferred for route type Originator: 4.4.4.4 Cluster list: 0.0.0.1 Not advertised to any peer yet

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

Issue 02 (2014-04-30)


78



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. ping 2.2.2.2 PING 2.2.2.2: 56 data bytes, press CTRL_C to break Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=254 time=70 Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=254 time=65 Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=254 time=64 Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=254 time=90 Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=254 time=25

ms ms ms ms ms


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

2.

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.

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

Issue 02 (2014-04-30)

If an ACL is configured to filter packets whose destination port is TCP port 179, delete the ACL configuration. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

79


3.


If no ACL is configured to filter packets whose destination port is TCP port 179, go to Step 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 f ollowing command output as an example: display bgp peer BGP local router ID : 223.5.0.109 Local AS number : 41976 Total number of peers : 12 Peer PrefRcv 8.9.0.8 10000 9.10.0.10 9999

Peers in established state : 4

V

AS

MsgRcvd

4

100

1601

4

200

1565

MsgSent 1443 1799

OutQ

Up/Down

State

0 23:21:56 Established 0 23:15:30 Established

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.

4.

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 t o 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.

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. display bgp peer BGP local router ID : 223.5.0.109 Local AS number : 41976 Total number of peers : 12 Peer PrefRcv 8.9.0.8 10000 9.10.0.10 9999


V

AS

MsgRcvd

4

100

1601

4

200

1565

MsgSent 1443 1799

OutQ

Up/Down

State

0 23:21:56 Established 0 23:15:30 Established

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.

5.

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.

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.

Issue 02 (2014-04-30)


80



Table 5-1 Checklist for BGP configurations

6.

Item

Description

peer connect-interface interfacetype interface-number

If two ends use loopback interfaces to establish 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 tr igger 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 t he 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.



l


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

Prerequisite l


l


Issue 02 (2014-04-30)


81



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

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE0/2/0

network

GE1/0/0 POS3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

ATNA

CX600B

Procedure Step 1 Run the display mpls ldp peer command to view LDP peer information. 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 GigabitEthernet0/2/0 ------------------------------------------------------------------------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. 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 0000:00:22 12984/12991 Operational DU Active -------------------------------------------------------------------------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. 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 -------------------------------------------------------------------------------

Issue 02 (2014-04-30)


82



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

Issue 02 (2014-04-30)

:

2


83


Issue 02 (2014-04-30)

VrfIndex Fec Nexthop In-Label Out-Label In-Interface Out-Interface LspIndex Token FrrToken LsrType Outgoing token Label Operation Mpls-Mtu TimeStamp Bfd-State BGPKey

: : : : : : : : : : : : : : : : :

No VrfIndex Fec Nexthop In-Label Out-Label In-Interface Out-Interface LspIndex Token FrrToken LsrType Outgoing token Label Operation Mpls-Mtu TimeStamp Bfd-State BGPKey

: : : : : : : : : : : : : : : : : :

No VrfIndex Fec Nexthop In-Label Out-Label In-Interface Out-Interface LspIndex Token FrrToken LsrType Outgoing token Label Operation Mpls-Mtu TimeStamp Bfd-State BGPKey

: : : : : : : : : : : : : : : : : :

No VrfIndex Fec Nexthop In-Label Out-Label In-Interface Out-Interface LspIndex Token FrrToken

: : : : : : : : : : :


2.2.2.2/32 192.168.1.2 NULL 3 ---------GigabitEthernet0/2/0 72705 0x8000007 0x0 Ingress 0x0 PUSH ------

944sec -------3 2.2.2.2/32 192.168.1.2 1656 3 ---------GigabitEthernet0/2/0 72706 0x8000008 0x0 Transit 0x0 SWAP ------

944sec -------4 3.3.3.3/32 192.168.1.2 NULL 2075 ---------GigabitEthernet0/2/0 72707 0x8000009 0x0 Ingress 0x0 PUSH 1500

944sec -------5 3.3.3.3/32 192.168.1.2 1657 2075 ---------GigabitEthernet0/2/0 72708 0x800000a 0x0


84

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide LsrType Outgoing token Label Operation Mpls-Mtu TimeStamp Bfd-State BGPKey

: : : : : : :


Transit 0x0 SWAP 1500

944sec --------

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. ping lsp -a 1.1. 1.1 ip 3.3.3.3 3 2 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 Reply from 3.3.3.3: bytes=100 Sequence=2 time = 27 ms Reply from 3.3.3.3: bytes=100 Sequence=3 time = 25 ms Reply from 3.3.3.3: bytes=100 Sequence=4 time = 24 ms Reply from 3.3.3.3: bytes=100 Sequence=5 time = 24 ms --- FEC: IPV4 PREFIX 3.3.3.3/32 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 24/25/27 ms

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.

2.

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.

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.

Issue 02 (2014-04-30)

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

85


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.

4.

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.

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.

5.

l

If the Hello-hold timer expires, see the troubleshooting of high CPU usage.

l

If the Hello-hold timer does not expire, go t o Step 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.

6.

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.


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 l


l


Context On the network shown in Figure 5-7, MPLS TE is configured on the network.

Issue 02 (2014-04-30)


86



Figure 5-7 Typical networking for configuring MPLS TE 1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE0/2/0

network

GE1/0/0 POS3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

ATNA

CX600B

Procedure Step 1 Run the display interface tunnel command on the commissioning device to view basic information about tunnel interfaces. display interface tunnel Tunnel0/2/0 current state : UP Line protocol 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 Route Port,The Maximum Transmit Unit is 1500 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. 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. display mpls te cspf tedb all Maximum Nodes Supported: 2000 Current Total Node Number: 3

Issue 02 (2014-04-30)


87



Maximum Links Supported: 8000 Maximum SRLGs supported: 10000

Current Total Link Number: 4 Current Total SRLG Number: 0

Id 1 2 3

Process-Id 1 1 1

Router-Id 1.1.1.1 2.2.2.2 3.3.3.3

IGP ISIS ISIS ISIS

Area Level-2 Level-2 Level-2

Link-Count 1 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 RSVPTE configurations on the interface. display mpls rsvp-te interface Interface: GigabitEthernet0/2/0 Interface Address: 192.168.1.1 Interface Index: 0x2f57 Interface state: UP

Total-BW: 100000

Used-BW: 20000

Hello configured: NO SRefresh feature: DISABLE Mpls Mtu: 1500 Increment Value: 1 Authentication: DISABLE Bfd Enabled: DISABLE Bfd Min-Rx: 10

Num of Neighbors: 1 SRefresh Interval: 30 sec Retransmit Interval: 5000 msec

Bfd Min-Tx: 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. display mpls rsvp-te peer Remote Node id Neighbor Neighbor Addr ----SrcInstance: 0xAAAD648C PSB Count: 1 Hello Type Sent: NONE SRefresh Enable: NO Last valid seq # rcvd: NULL Interface GigabitEthernet0/2/0 Neighbor Addr: 192.168.1.2 SrcInstance: 0xAAAD648C PSB Count: 2 Hello Type Sent: NONE SRefresh Enable: NO Last valid seq # rcvd: NULL

NbrSrcInstance: 0x0 RSB Count: 2

NbrSrcInstance: 0x0 RSB Count: 1

Step 6 Run the ping lsp command on the commissioning device to test the availability of the TE tunnel. ping lsp te tunn el 0/2/0 LSP PING FEC: RSVP IPV4 SESSION to break Reply from 20.1.1.2: bytes=100 Reply from 40.1.1.2: bytes=100 Reply from 20.1.1.2: bytes=100 Reply from 40.1.1.2: bytes=100 Reply from 20.1.1.2: bytes=100

QUERY Tunnel0/2/0 : 100 Sequence=0 Sequence=1 Sequence=2 Sequence=3 Sequence=4

time time time time time

= = = = =

data bytes, press CTRL_C

50 ms 28 ms 33 ms 52 ms 8 ms

--- FEC: RSVP IPV4 SESSION QUERY Tunnel0/2/0 ping statistics --5 packet(s) transmitted 5 packet(s) received

Issue 02 (2014-04-30)


88



0.00% packet loss round-trip min/avg/max = 8/34/52 ms

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

2.

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.

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 t he 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

3.

If CSPF has been successfully calculating paths but the fault persists, go to Step 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 pathname 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 currentconfiguration interface interface-name command to check if RSVP is enabled.

4.

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.

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. Issue 02 (2014-04-30)


89



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

5.

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.



l


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

Prerequisites l


l


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

192.168.1.1/24 100.1.1.1/24 100.1.2.1/24 GE0/2/0 GE1/0/0 GE2/0/0 GE2/0/0 GE0/2/1 192.168.1.2/24 100.1.2.2/24 100.1.1.2/24 GE1/0/0 CE1 PE1 CE2 PE2

Procedure Step 1 Run the display ip vpn-instance verbose command on the commissioning device to check that VPN instance configurations are correct. display ip vpn-instance verbose Total VPN-Instances configured : 1

Issue 02 (2014-04-30)


90



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. display BGP local router Local AS number Total number of

bgp vpnv4 all peer ID : 1.1.1.1 : 100 peers : 2


Peer V AS MsgRcvd MsgSent 2.2.2.2 4 274 10 12 Peer of IPv4-family for vpn instance : VPN-Instance vpna, router ID 1.1.1.1: 100.1.1.1 4 65410 454 418

OutQ 0

Up/Down 03:24:40

State PrefRcv 0 Established

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. display bgp vpnv4 vpn-instance vpna routing-table peer 100.1.1.1

advertised-routes 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: 6 Network NextHop MED LocPrf PrefVal Path/ 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? display bgp vpnv4 vpn-instance vpna routing-table peer 100.1.1.1 received-

routes 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 VPN-Instance vpna, router ID 1.1.1.1: Total Number of Routes: 6 Network NextHop MED LocPrf PrefVal Path/ 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?

Issue 02 (2014-04-30)


91



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 t he 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. display ip routing-table vpn-instance vpna Route Flags: R - relay, D - download to fib -----------------------------------------------------------------------------Routing Tables: vpna Destinations : 3 Routes : 3 Destination/Mask Proto Pre Cost Flags NextHop Interface 100.1.1.0/24 Direct 0 0 D 10.1.1.2 GigabitEthernet0/2/1 100.1.1.2/32 Direct 0 0 D 127.0.0.1 InLoopBack0 100.1.1.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0

100.1.2.0/24

BGP

255.255.255.255/32 Direct

255 0

0 0

RD D

2.2.2.2 127.0.0.1

GigabitEtherne t0/2/0 InLoopBack0

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. ping -vpn-instan ce vpna 100.1.2. 2 PING 100.1.2.2: 56 data bytes, press CTRL_C to break Reply from 100.1.2.2: bytes=56 Sequence=1 ttl=255 time=56 ms Reply from 100.1.2.2: bytes=56 Sequence=2 ttl=255 time=4 ms Reply from 100.1.2.2: bytes=56 Sequence=3 ttl=255 time=4 ms Reply from 100.1.2.2: bytes=56 Sequence=4 ttl=255 time=52 ms Reply from 100.1.2.2: bytes=56 Sequence=5 ttl=255 time=3 ms --- 100.1.2.2 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 3/23/56 ms

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 ipv4address [ 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. Issue 02 (2014-04-30)


92



display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1 BGP local router ID : 20.1.1.2 Local AS number : 100 VPN-Instance vpna, router ID 20.1.1.2: Paths: 1 available, 1 best, 1 select BGP routing table entry information of 1.1.1.1/32: Imported route. From: 20.1.1.1 (1.1.1.1) Route Duration: 00h00m03s Direct Out-interface: GigabitEthernet0/2/1 Relay IP Nexthop: 20.1.1.2 Relay IP Out-Interface: GigabitEthernet0/2/0 Original nexthop: 3.3.3.3 Qos information : 0x0 AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid , internal, best, select, active, pre 255 Not advertised to any peer yet 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. display current-configuration configuration bgp # bgp 100 peer 1.1.1.1 as-number 200

Issue 02 (2014-04-30)


93



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 as-number 300 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

l

3.

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 . If inbound and outbound policies are not configured on the t wo ends, go to Step 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. display bgp vpnv4 all routing-table 50.1.1.2 BGP local router ID : 2.2.2.2 Local AS number : 100 Total routes of Route Distinguisher(1:2): 1 BGP routing table entry information of 50.1.1.2/32: Imported route. Label information (Received/Applied): 13316/NULL From: 1.1.1.1 (1.1.1.1) Route Duration: 00h00m08s Relay IP Nexthop: 20.1.1.1 Relay IP Out-Interface: GigabitEthernet0/2/0 Relay Tunnel Out-Interface: GigabitEthernet0/2/0 Relay token: 0x1002 Original nexthop: 1.1.1.1 Qos information : 0x0 Ext-Community:RT <1 : 1> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Not advertised to any peer yet

Issue 02 (2014-04-30)


94



VPN-Instance vpna, router ID 2.2.2.2: Total Number of Routes: 1 BGP routing table entry information of 50.1.1.2/32: Imported route. Label information (Received/Applied): 13316/NULL From: 1.1.1.1 (1.1.1.1) Route Duration: 00h00m07s Relay Tunnel Out-Interface: GigabitEthernet0/2/0 Relay token: 0x1002 Original nexthop: 1.1.1.1 Qos information : 0x0 AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255 Not advertised to any peer yet

4.

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.

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

5.

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.

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 routingtable 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. display bgp vpnv4 all routing-table 100.1.1.1 BGP local router ID : 10.1.1.2 Local AS number : 100 Total routes of Route Distinguisher(1:1): 1

Issue 02 (2014-04-30)


95



BGP routing table entry information of 100.1.1.0/24: Imported route. Label information (Received/Applied): NULL/13312 From: 0.0.0.0 (0.0.0.0) Route Duration: 00h21m24s Direct Out-interface: GigabitEthernet0/2/1 Original nexthop: 100.1.1.1 Qos information : 0x0 Ext-Community:RT <1 : 1> AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, selec t, pre 255 Advertised to such 1 peers: 1.1.1.1 VPN-Instance vpna, router ID 10.1.1.2: Total Number of Routes: 1 BGP routing table entry information of 100.1.1.0/24: Imported route. From: 0.0.0.0 (0.0.0.0) Route Duration: 00h21m24s Direct Out-interface: GigabitEthernet0/2/1 Original nexthop: 100.1.1.1 Qos information : 0x0 AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select,pre 0 Not advertised to any peer yet

6.

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.

Check that the number of routes does not exceed the limit. Run the display current-configuration configuration bgp | include peer destinationaddress 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. display current-configuration configuration bgp | include peer

1.1.1.1 peer 1.1.1.1 as-number 100 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. display current-configuration configuration bgp | include peer

1.1.1.1 peer 1.1.1.1 as-number 100 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. 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 i s interrupted, the target route is dropped because the route limit has been exceeded, and the limit needs to be increased. Issue 02 (2014-04-30)


96



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.

7.



l


5.8 Commissioning VPWS This section describes how to commission VPWS.

Prerequisite l


l


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 100.1.1.1/24 GE1/0/0.1 GE0/2/1.1 CE1

2.2.2.2/32

192.168.1.1/24 GE0/2/0

100.1.1.2/24 GE2/0/0.1 GE2/0/0.1

192.168.1.2/24 GE1/0/0 PE2

PE1

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. display mpls l2vc

total LDP VC : 1 *client interface Administrator PW session state AC status VC state Label state Token state VC ID VC type destination local VC label control word forwarding entry local group ID manual fault

Issue 02 (2014-04-30)

1 : : : : : : : : : : : : : : :

up 0 down GigabitEthernent 0/2/1.1 up up up up 0 0 101 VLAN 2.2.2.2 21504 remote VC label disable existent 0 not set


: 21504

97

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide active state

: link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time : CKey : NKey : AdminPw interface : AdminPw link state : Diffserv Mode : Service Class : Color : DomainId : Domain Name :


active

up 1500 remote VC MTU to2 --primary 0 days, 0 hours, 6 minutes, 0 days, 0 hours, 4 minutes, 0 days, 0 hours, 4 minutes, 2010/07/24 12:31:31 0 days, 0 hours, 4 minutes, 16 15 --uniform -----

: 1500

4 seconds 34 seconds 34 seconds 34 seconds

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. display l2vpn ccc-interface vc-type all Total ccc-interface of LDP VC: 1 up (1), down (0) Interface Encap Type State GigabitEthernet1/0/0.1 vlan up

VC Type

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.

Step 3 Run the ping command on CE1 to test the connectivity of the link between CE1 and CE2. ping 100.1.1.2 PING 100.1.1.2: 56 data bytes, press CTRL_C to break Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255

time=56 ms time=4 ms time=4 ms time=52 ms time=3 ms



Troubleshooting If the VC of a Martini VLL cannot become Up, complete the following: 1.

Issue 02 (2014-04-30)

Check that the two ends of the VC are configured with the same encapsulation type and MTU. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

98



Run the display mpls l2vc vc-id command command to view VC information. display mpls l2vc 102 total LDP VC : 1 1 up 0 down *client interface : GigabitEthernet0 GigabitEthernet0/2/1.5 /2/1.5 session state : up AC status : up VC state : up VC ID : 102 VC type : VLAN destination : 2.2.2.2 local VC label : 146433 remote VC label : 146432 control word : disable forwarding entry : exist local group ID : 0 manual fault : not set active state : active link state : up local VC MTU : 1500 remote VC MTU : 1500 tunnel policy name : -traffic behavior name: - PW template name : -primary or secondary : primary create time : 1 days, 1 hours, 14 minutes, 17 seconds up time : 0 days, 0 hours, 3 minutes, 16 seconds last change time : 0 days, 0 hours, 3 minutes, 16 seconds VC last up time : 2010/02/17 08:23:07 VC total up time : 0 days, 21 hours, 43 minutes, 43 seconds CKey : 16 NKey : 15 AdminPw interface : -AdminPw link state : -Diffserv Mode : uniform 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 Check that that the the VC IDs of the the two two ends ends of the the VC VC are are the the same. same. display mpls l2vc 102 total LDP VC : 1 1 up 0 down *client interface : GigabitEthernet0 GigabitEthernet0/2/1.5 /2/1.5 session state : up AC status : up VC state : up VC ID : 102 VC type : VLAN destination : 2.2.2.2 local VC label : 146433 remote VC label control word : disable forwarding entry : exist local group ID : 0 manual fault : not set active state : active link state : up local VC MTU : 1500 remote VC MTU

Issue 02 (2014-04-30)


: 146432

: 1500

99

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time : CKey : 16 NKey : AdminPw interface : AdminPw link state : Diffserv Mode : Service Class : Color : DomainId : Domain Name :

5 Commissioning Services and Protocols ---primary 1 days, 1 hours, 14 minutes, 17 seconds 0 days, 0 hours, 3 minutes, 16 seconds 0 days, 0 hours, 3 minutes, 16 seconds 2010/02/17 08:23:07 0 days, 21 hours, 43 minutes, 43 seconds

15 --uniform -----

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 Check that that the the LDP LDP sessi session on betw between een the two ends ends is Up. Up. display mpls l2vc 102 total LDP VC : 1 1 up 0 down *client interface : GigabitEthernet0 GigabitEthernet0/2/1.5 /2/1.5 session state : up AC status : up VC state : up VC ID : 102 VC type : VLAN destination : 2.2.2.2 local VC label : 146433 remote VC label : 146432 control word : disable forwarding entry : exist local group ID : 0 manual fault : not set active state : active link state : up local VC MTU : 1500 remote VC MTU : 1500 tunnel policy name : -traffic behavior name: - PW template name : -primary or secondary : primary create time : 1 days, 1 hours, 14 minutes, 17 seconds up time : 0 days, 0 hours, 3 minutes, 16 seconds last change time : 0 days, 0 hours, 3 minutes, 16 seconds VC last up time : 2010/02/17 08:23:07 VC total up time : 0 days, 21 hours, 43 minutes, 43 seconds CKey : 16 NKey : 15 AdminPw interface : -AdminPw link state : -Diffserv Mode : uniform Service Class : -Color : -DomainId : -Domain Name : --

Issue 02 (2014-04-30)


100



If the LDP session is Down, see the section "LDP Session Goes Down" in ATN in ATN Multi service Access Equipment Equipment Troubleshooting to 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.

Chec Check k that that the the PW PW has has sele select cted ed a tunn tunnel el.. Run the display mpls l2vc vc-id command. command. l

Check the VC tunnel/token info field in the command output. If VC tunnel/token info is displayed as 0 tunnels/tokens 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 } 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 in ATNMulti-service Access Access Equipment Troubleshooting to 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 Check that that the AC inte interfa rface cess on the two ends ends are are Up. Up. Run the display mpls l2vc vc-id command 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 in ATN Multi-service Access Access Equipment Troubleshooting Troubleshooting to 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.

6.

Issue 02 (2014-04-30)

Collect Collect the following following informatio information n and contact contact Huawei Huawei technical technical support support personn personnel: el: l


l



101



5.9 Commissioning VPLS This section describes how to commission VPLS.

Prerequisite l


l


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 100.1.1.1/24 GE1/0/0.1 GE0/2/1.1 CE1

2.2.2.2/32

192.168.1.1/24 GE0/2/0

100.1.1.2/24 GE2/0/0.1 GE2/0/0.1

192.168.1.2/24 GE1/0/0 PE2

PE1

CE2

Procedure Step 1 Run the display vsi command on the commissioning device to view VSI information. display vsi name v1 verbose ***VSI Name Administrator VSI Isolate Spoken VSI Index

Issue 02 (2014-04-30)

: : : :

v1 no disable 1

PW Signaling : ldp Member Discovery Style : static PW MAC Learn Style : unqualify Encapsulation Type : vlan MTU : 1500 Diffserv Mode : uniform Service Class : -Color : -DomainId : 255 Domain Name : Ignore AcState : disable Multicast Fast Swicth : enable Create Time : 0 day s, 0 hours, 50 minutes, 23 seconds VSI State : up VSI ID *Peer Router ID primary or secondary ignore-standby-state VC Label Peer Type Session Tunnel ID

: : : : : : : :

10 2.2.2.2 primary no 23552 dynamic up 0x10002000


102



Broadcast Tunnel ID Broad BackupTunnel ID CKey NKey StpEnable PwIndex

: : : : : :

0x10002000 0x0 6 5 0 0

Interface Name

: GigabitEthernet0/2/1.1

State Last Up Time Total Up Time

: 2010/08/15 15:41:59 : 0 days, 0 hours, 19 minutes, 18 seconds

: up

**PW Information:

*Peer Ip Address PW State Local VC Label Remote VC Label PW Type Tunnel ID Broadcast Tunnel ID Broad BackupTunnel ID Ckey Nkey Main PW Token Slave PW Token Tnl Type OutInterface GigabitEthernet1/0/0 Backup OutInterface Stp Enable Mac Flapping PW Last Up Time PW Total Up Time

: : : : : : : : : : : : : : : : : : :

2.2.2.2 up 23552 23552 label 0x10002000 0x10002000 0x0 0x6 0x5 0x10002000 0x0 LSP

0 0 2010/08/15 15:41:59 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. display vpls forwarding-info Total Number : 2, 2 up, 0 down Vsi-Name V1

Issue 02 (2014-04-30)

PeerIP 2.2.2.2

VcOrSiteId 1

PwState UP


103



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. display l2vpn vsi-list tunnel-policy p1 Using Tunnel-Policy p1 VSI Instance statistics: ---------------------------------------------------------------------vsi v1

Step 4 Run the ping command on CE1 to test the connectivity of the link between CE1 and CE2. ping 100.1.1.2 PING 100.1.1.2: 56 data bytes, press CTRL_C to break Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255

time=56 ms time=4 ms time=4 ms time=52 ms time=3 ms



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. 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. display vsi name tt Vsi Mem PW Mac Encap Mtu Vsi Name Disc Type Learn Type Value State -------------------------------------------------------------------------tt static ldp unqualify vlan up 1500

Issue 02 (2014-04-30)

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

104



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. display vsi name tt verbose ***VSI Name Administrator VSI Isolate Spoken VSI Index PW Signaling Member Discovery Style PW MAC Learn Style Encapsulation Type MTU Diffserv Mode Service Class Color DomainId Domain Name Tunnel Policy Name Ignore AcState Create Time VSI State

: : : : : : : : : : : : : : : : : :

VSI ID *Peer Router ID VC Label Peer Type Session Tunnel ID Broadcast Tunnel ID CKey NKey StpEnable PwIndex

: : : : : : : : : : :

2.2.2.2 187393 dynamic up 0xc0060401 0xc0060401 6 5 0 0

: : : :

GigabitEthernet0/2/0.12 up 2010/02/05 06:36:57 2 days, 2 hours, 40 minutes, 19 seconds

Interface Name State Last Up Time Total Up Time

tt no disable 3 ldp static unqualify vlan 1500 uniform --255 p1 disable 2 days, 2 hours, 47 minutes, 40 seconds up

101

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 negotiationVC-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. display vsi name tt verbose ***VSI Name Administrator VSI Isolate Spoken VSI Index PW Signaling Member Discovery Style

Issue 02 (2014-04-30)

: : : : : :

tt no disable 3 ldp static


105



PW MAC Learn Style Encapsulation Type MTU Diffserv Mode Service Class Color DomainId Domain Name Tunnel Policy Name Ignore AcState Create Time VSI State

: : : : : : : : : : : :

unqualify vlan 1500 uniform --255

VSI ID *Peer Router ID VC Label Peer Type Session Tunnel ID Broadcast Tunnel ID CKey NKey StpEnable PwIndex

: : : : : : : : : : :

101 2.2.2.2 187393 dynamic 0xc0060401 0xc0060401 6 5 0 0

: : : :

GigabitEthernet0/2/0.12 up 2010/02/05 06:36:57 2 days, 2 hours, 40 minutes, 19 seconds

Interface Name State Last Up Time Total Up Time

p1 disable 2 days, 2 hours, 47 minutes, 40 seconds up

up

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 MPLSTE 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. Issue 02 (2014-04-30)


106



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.

7.



l


5.10 Commissioning BFD This section describes how to commission BFD. BFD sessions can quickly detect link faults on a network.

Prerequisite l


l


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

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE0/2/0

network

GE1/0/0 POS3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

ATNA

CX600B

Procedure Step 1 Run the display current-configuration command on the commissioning device to check if BFD parameters have taken effect. display current-configuration | begin peer-ip bfd to_net_comm bind default-ip interface GigabitEthernet0/2/0 discriminator local 1 discriminator remote 2

Issue 02 (2014-04-30)


107



detect-multiplier 10 wtr 5

process-interfac e-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. display bfd session all -------------------------------------------------------------------------------Type InterfaceName Local Remote PeerIpAddr State -------------------------------------------------------------------------------192.168.0.2 S_IP_IF GigabitEtherne t0/2/0 1 2 Up -------------------------------------------------------------------------------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. display bfd session all verbose -------------------------------------------------------------------------------Session MIndex : 16384 Name : atob (One Hop) State : Up -------------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(Giga bitEthernet0/2/0 bitEthernet0/2/0) ) Bind Session Type : Static Bind Peer Ip Address : 192.168.1.2 NextHop Ip Address : 192.168.1.2 Bind Interface : GigabitEtherne t0/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 Process PST : Disable Proc interface status : Enable 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 singlehop BFD session is set up in the Up st ate. 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: Issue 02 (2014-04-30)


108


1.


current-configuration configuration bfd-session command to check Run the display current-configuration 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.

3.

4.

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.

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.

Run the display bfd statistics session all command repeatedly to check that the Send Bad Packets value increases properly. l

l

5.

6.

Issue 02 (2014-04-30)

If the Send Bad Packets value increases, the BFD packets are sent but discarded. In this case, go to Step 7. 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.

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.

current-configuration configuration bfd-session command to check the Run the display current-configuration 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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

109


7.


Collect Collect the following following informatio information n and contact contact Huawei Huawei technical technical support support personn personnel. el. l


l


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

l

The DCN-enabled interface on the ATN device is up.

Context As shown in Figure 5-12, 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 5-12 Typical networking diagram for DCN commissioning

NEID:0x11111

NEID:0x22222

NEIP:128.1.17.17

NEIP:128.2.34.34

Console PC

ATNA

GE0/2/0 GE1/0/0

network

CX600B

Procedure command to view the DCN information about Step 1 On the ATN device, run the display dcn brief command the ATN device. display dcn display dcn brief -----------------------------------------------NE-ID: 0x11111 NE-IP: 128.1.17.17 Mask: 255.255.0.0 DCN-Interface: LoopBack1023 Auto-Report: Disable ------------------------------------------------

current-configuration command to view the default DCN Step 2 On the ATN device, run the display current-configuration

configurations. Issue 02 (2014-04-30)


110



display current-configuration # 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. 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. display dcn ne-info Route Flags: R - relay, D - download to fib -----------------------------------------------------------------------------Routing Tables: __dcn_vpn__ Destinations : 6 Routes : 6 Destination/Mask

Proto

Pre

Cost

Flags NextHop

128.1.0.0/16 Direct 0 0 128.1.17.17/32 Direct 0 0 128.1.255.255/32 Direct 0 0

128.2.34.34/32 Direct 0 Serial0/2/2:0 255.255.255.255/32 Direct

D D

0 0

128.1.17.17 127.0.0.1 D 127.0.0.1

D 0

128.2.34.34 D

127.0.0.1

Interface LoopBack1023 LoopBack1023 LoopBack1023

DCNInLoopBack0

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. Issue 02 (2014-04-30)


111



ping -vpn-instan ce __dcn_vpn__ 1 28.2.34.34 PING 128.2.34.34: 56 data bytes, press CTRL_C to break Reply from 128.2.34.34: bytes=56 Sequence=1 ttl=255 ms Reply from 128.2.34.34: bytes=56 Sequence=2 ttl=255 ms Reply from 128.2.34.34: bytes=56 Sequence=3 ttl=255 ms Reply from 128.2.34.34: bytes=56 Sequence=4 ttl=255 ms Reply from 128.2.34.34: bytes=56 Sequence=5 ttl=255 ms

time=1 time=1 time=1 time=1 time=1


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

Handling Common Faults 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.

Issue 02 (2014-04-30)


112



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


l


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 As shown in Figure 5-13, 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 5-13 Typical networking diagram for clock commissioning 2.2.2.2/32

1.1.1.1/32

Console PC

192.168.1.1 / 24 GE0/2/0

network

GE1/0/0 192.168.1.2 / 24

ATNA

POS3/0/0 192.167.1.10 / 24

CX600B

Procedure Step 1 On the ATN device, run the display clock source command to view information about the clock source. 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

Issue 02 (2014-04-30)


113

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide Frequency lock success:

5 Commissioning Services and Protocols 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. 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. system [HUAWEI] display ptp-adaptive all Device config info ------------------------------------------------------------------------

Issue 02 (2014-04-30)


114

ATN 910&910I&910B&950B Multi-Service Access Equipment Commissioning Guide Ptp adaptive state : Sync mode : Packet dscp : Announce interval : Sync interval : Announce receipt timeout: Local ip :

Ptp port name

5 Commissioning Services and Protocols Enable Frequency 56 11 3 8s 81.0.1.21

Device type Current state Domain value Announce duration Sync duration Acr mode

: : : : : :

client slave 0 80s 80s One-way

: GigabitEtherne t0/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

Handling Common Faults N/A

Issue 02 (2014-04-30)


115


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, including SNMP read and write community names and the ACL number.

l

read community name: Com#access

l

write community name: Mgr#access

l

ACL number: 2000

l

read community name: Com#access

l

write community name: Mgr#access

l

ACL number: 2001

Parameters of SNMPv2c, including SNMP read and write community names and the ACL number.

Issue 02 (2014-04-30)


None.

None.

116



Item

Data

Parameters of SNMPv3, including SNMP group and user names and the ACL number.

l

SNMP group name: NMS

l

SNMP user name: John

l

ACL number: 2002

Remarks None.

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. system-view [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 snmpagent 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 securit yname Com#access v1 private-netm anager l

Configure SNMPv2c. 1.

Configure basic functions of SNMPv2c on the ATN. # Configure SNMP version. system-view [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 snmpagent community. Issue 02 (2014-04-30)


117



[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 [HUAWEI-acl-basic-2001] rule permit source 192.167.1.10 0 [HUAWEI-acl-basic-2001] 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. For more information, see snmp-agent target-host trap. NOTE


params securit yname Com#access v1 private-netm anager l

Configure SNMPv3. 1.

Configure basic functions of SNMPv3 on the ATN. ATN # Configure SNMP version. system-view [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 [HUAWEI-acl-basic-2002] rule permit source 192.167.1.10 0 [HUAWEI-acl-basic-2002] quit

# Apply the ACL based on the user. For more information, see the command snmpagent usm-user. [HUAWEI] snmp-agent usm-user v3 John NMS acl 2002

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. For more information, see the command snmp-agent target-host trap. NOTE


params securit yname Com#access v3 private-netm anager

----End Issue 02 (2014-04-30)


118

ATN_910_and_910I_and_910B_and_950B_Multi.pdf

Recommend Documents