Commission Guide(V600R003C00 02)

HUAWEI NetEngine80E/40E Router V600R003C00

Commissioning Guide Issue

02

Date

2011-09-10

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd. Address:

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

Website:

http://www.huawei.com

Email:

[email protected]

Issue 02 (2011-09-10)

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

i

HUAWEI NetEngine80E/40E Router Commissioning Guide

About This Document

About This Document Purpose This document is a guide to NE80E/40E commissioning and verification. It describes how to commission hardware, links, services, and maintenance and management during deployment, ensuring stable and reliable operation of NE80E/40Es on networks. The intended audience of this document includes installation and commissioning engineers. NOTE

l This document takes interface numbers and link types of the NE40E-X8 as an example. In working situations, the actual interface numbers and link types may be different from those used in this document. l In NE80E/40E series (except for the NE40E-X1/X2), line processing boards are called Line Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). The NE40E-X1/ X2 has no LPU and SFU, and packet switching and forwarding are centrally performed by the Network Processing Unit (NPU).

Related Versions The following table lists the product versions related to this document. Product Name

Version

HUAWEI NetEngine80E/40E Router

V600R003C00

Intended Audience This document is intended for: l

Data configuration engineers

l

Commissioning engineers

l

Network monitoring engineers

l

System maintenance engineers

Issue 02 (2011-09-10)


ii


About This Document

Symbol Conventions The symbols that may be found in this document are defined as follows. Symbol

Description

DANGER

WARNING

CAUTION

Alerts you to a high risk hazard that could, if not avoided, result in serious injury or death. Alerts you to a medium or low risk hazard that could, if not avoided, result in moderate or minor injury. Alerts you to a potentially hazardous situation that could, if not avoided, result in equipment damage, data loss, performance deterioration, or unanticipated results.

TIP

Provides a tip that may help you solve a problem or save time.

NOTE

Provides additional information to emphasize or supplement important points in the main text.

Command Conventions The command conventions that may be found in this document are defined as follows.

Issue 02 (2011-09-10)

Convention

Description

Boldface

The keywords of a command line are in boldface.

Italic

Command arguments are in italics.

[]

Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... }

Optional items are grouped in braces and separated by vertical bars. One item is selected.

[ x | y | ... ]

Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected.

{ x | y | ... }*

Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected.

[ x | y | ... ]*

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

&<1-n>

The parameter before the & sign can be repeated 1 to n times.

#

A line starting with the # sign is comments.


iii


About This Document

Change History Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.

Changes in Issue 02 (2011-09-10) Second commercial release.

Changes in Issue 01 (2011-06-30) Initial commercial release.

Issue 02 (2011-09-10)


iv


Contents

Contents About This Document.....................................................................................................................ii 1 Commissioning Flow....................................................................................................................1 2 Logging In to the NE80E/40E.......................................................................................................3 2.1 Logging In to the NE80E/40E by Using the Console Interface.........................................................................4 2.2 Logging In to the NE80E/40E by Using Telnet.................................................................................................7 2.3 Logging In to the NE80E/40E by Using SSH..................................................................................................10

3 Checking the Hardware..............................................................................................................16 3.1 Checking the Software Version........................................................................................................................17 3.2 Checking the Health Status of the NE80E/40E................................................................................................18 3.3 Checking the Board Registration Status...........................................................................................................18 3.4 Checking the Fan Status...................................................................................................................................20 3.5 Checking the Power Status...............................................................................................................................21 3.6 Checking System Time.....................................................................................................................................22 3.7 Checking the Interface Status...........................................................................................................................22 3.8 Checking Alarm Information............................................................................................................................24 3.9 Checking the Voltage of Each Board...............................................................................................................25 3.10 Checking the Temperature of Each Board......................................................................................................26

4 Commissioning the Link Layer................................................................................................28 4.1 Checking Ethernet Interfaces............................................................................................................................29 4.2 Checking POS Interfaces..................................................................................................................................31 4.3 Checking CPOS Interfaces...............................................................................................................................34 4.4 Checking E-Carrier and T-Carrier Interfaces...................................................................................................37 4.5 Checking ATM Interfaces................................................................................................................................39 4.6 Checking FR Interfaces....................................................................................................................................42 4.7 Checking the Optical Power of Interfaces........................................................................................................43

5 Commissioning Services and Protocols..................................................................................46 5.1 Commissioning Static Routes...........................................................................................................................48 5.2 Commissioning OSPF Routes..........................................................................................................................49 5.3 Commissioning IS-IS Routes...........................................................................................................................56 5.4 Commissioning IBGP Routes...........................................................................................................................60 5.5 Commissioning EBGP Routes..........................................................................................................................66 Issue 02 (2011-09-10)


v


Contents

5.6 Commissioning MPLS LDP.............................................................................................................................72 5.7 Commissioning MPLS TE................................................................................................................................76 5.8 Commissioning BGP/MPLS IP VPN...............................................................................................................80 5.9 Commissioning VPWS.....................................................................................................................................87 5.10 Commissioning VPLS....................................................................................................................................91 5.11 Commissioning BFD......................................................................................................................................97

6 Commission Examples.............................................................................................................100 6.1 Example for Commissioning an IP Bearer Network......................................................................................101

A List of Interface Attributes.....................................................................................................112 A.1 Interface Attributes of 100Base-FX...............................................................................................................113 A.2 Interface Attributes of 100/1000Base-CSFP.................................................................................................113 A.3 Interface Attributes of 1000Base-X-SFP.......................................................................................................114 A.4 Interface Attributes of 10GBase LAN/WAN-XFP........................................................................................116 A.5 Interface Attributes of 10GBase LAN-SFP+.................................................................................................117 A.6 Interface Attributes of OC-3c/STM-1c cPOS-SFP........................................................................................117 A.7 Interface Attributes of OC-3c/STM-1c POS-SFP.........................................................................................118 A.8 Interface Attributes of OC-12c/STM-4c POS-SFP.......................................................................................119 A.9 Interface Attributes of OC-48c/STM-16c POS-SFP.....................................................................................120 A.10 Interface Attributes of OC-192c/STM-64c POS-XFP.................................................................................121 A.11 Interface Attributes of OC-3c/STM-1c ATM-SFP......................................................................................122 A.12 Interface Attributes of OC-12c/STM-4c ATM-SFP....................................................................................123

Issue 02 (2011-09-10)


vi


1 Commissioning Flow

1

Commissioning Flow

This section describes the NE80E/40E commissioning flow. Users can know the entire process of NE80E/40E commissioning in site deployment after reading this section. Figure 1-1 Commissioning flow Logging In to the NE40E Checking the Hardware Commissioning the Link Layer Commissioning Services and Protocols

Table 1-1 Commissioning procedures

Issue 02 (2011-09-10)

Commissioning Procedure

Description

Logging In to the NE80E/40E

Describes how to log in to the NE80E/40E for later commissioning. Three login methods, login by using the console interface, Telnet, and Secure Shell (SSH), are introduced.

Checking the Hardware

Describes how to check power supply, fans, boards, and interfaces to prepare for NE80E/ 40E commissioning.

Commissioning the Link Layer

Describes how to commission the link layer when the NE80E/40E is connected to otherrouters ortransport devices.


1


Issue 02 (2011-09-10)

1 Commissioning Flow

Commissioning Procedure

Description

Commissioning Services and Protocols

Describes how to commission services and protocols, especially routing protocols, tunnel services, VPN services, and BFD functions, when the NE80E/40E is connected to other routers or transport devices.


2


2 Logging In to the NE80E/40E

2

Logging In to the NE80E/40E

About This Chapter This section describes how to log in to the NE80E/40E for later commissioning. Three login methods, login by using the console interface, Telnet, and SSH, are introduced. 2.1 Logging In to the NE80E/40E by Using the Console Interface When setting up a local configuration environment with the console interface being used, you can log in to the NE80E/40E by using the HyperTerminal in Windows on the PC. 2.2 Logging In to the NE80E/40E by Using Telnet This section describes how to log in to the NE80E/40E by using Telnet. A Telnet operation allows you to log in to a remote device for device management. 2.3 Logging In to the NE80E/40E by Using SSH This section describes how to log in to the NE80E/40E by using SSH. SSH is a secure remote login protocol, which is developed based on the traditional Telnet protocol. Compared with Telnet, SSH is greatly improved in terms of the authentication mode and data transmission security.

Issue 02 (2011-09-10)


3



2.1 Logging In to the NE80E/40E by Using the Console Interface When setting up a local configuration environment with the console interface being used, you can log in to the NE80E/40E by using the HyperTerminal in Windows on the PC.

Prerequisite Figure 2-1 Networking diagram of logging in to the NE80E/40E by using the console interface

PC

Router

l

The NE80E/40E is powered on and works properly.

l

The PC is connected to the NE80E/40E through asynchronous interfaces.

l

Installing terminal emulation program on the PC (such as Windows XP HyperTerminal) NOTE

Perform the following configurations on the HyperTerminal on the PC.

Procedure Step 1 Use a serial cable to connect the serial interface on the PC and the console interface on the NE80E/40E. For details about the console interface, see the HUAWEI NetEngine80E/40E Router Hardware Description. 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. As shown in Figure 2-2, enter the name of the new connection in the Name text box, and select an icon. Then, click OK.

Issue 02 (2011-09-10)


4



Figure 2-2 Setting up a connection

Step 4 Set a connection port. In the Connect To dialog box shown in Figure 2-3, 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-3 Setting a connection port

Step 5 Set communication parameters. When the COM1 Properties dialog box is displayed as shown in Figure 2-4, set the COM1 properties according to the description in Figure 2-4 or by clicking Restore Defaults. Issue 02 (2011-09-10)


5



NOTE

l Setting the COM1 properties according to the description in Figure 2-4 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 NE80E/40E by using the console interface, ensure that the COM1 properties on the HyperTerminal are consistent with the interface attribute settings on the NE80E/40E. Otherwise, the login will fail. This means that if default settings are not used for the interface attributes on the NE80E/40E, the COM1 properties on the HyperTerminal must be changed to be consistent with the interface attribute settings on the NE80E/40E.

Figure 2-4 Setting communication parameters

----End

Commissioning Result After the preceding configurations are complete, press Enter. If the prompt is displayed on the screen, logging in to the NE80E/40E by using the console interface is successful. Then, commands can be run to configure or manage the NE80E/40E. 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 NE80E/40E again.

Issue 02 (2011-09-10)


6



2.2 Logging In to the NE80E/40E by Using Telnet This section describes how to log in to the NE80E/40E by using Telnet. A Telnet operation allows you to log in to a remote device for device management.

Prerequisite Figure 2-5 Networking diagram of logging in to the NE80E/40E by using Telnet

network Telnet Client

Telnet Server

Before logging in to the NE80E/40E by using Telnet, complete the following tasks: l

Ensure that the NE80E/40E is working properly.

l

Log in to the NE80E/40E by using the console interface and configure an IP address for each interface on the NE80E/40E.

l

Ensure that there is a direct or reachable route between the Telnet client and the NE80E/ 40E. NOTE

Perform the following configurations on the NE80E/40E that serves as the Telnet server:

Procedure Step 1 Set the maximum number of users that are allowed to log in to the NE80E/40E at the same time. 1.

Run the system-view command to enter the system view.

2.

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

Step 2 Configure a user authentication mode. Three authentication modes are available: password authentication, AAA authentication, and non-authentication. One of them can be selected as needed. NOTE

l On the router, the default authentication mode is password authentication. l Non-authentication is not recommended because the router may be vulnerable to security threats in non-authentication mode. l If users with passwords need to be created and managed on the router, AAA authentication is recommended.

l Configure password authentication. 1. Issue 02 (2011-09-10)

Run the system-view command to enter the system view. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

7



2.

Run the user-interface [ ui-type ] first-ui-number [ last-ui-number ] command to enter the user interface view.

3.

Run the set authentication password { cipher | simple } password command to set the password used in authentication.

l Configure AAA authentication. 1.


2.


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 { simple | cipher } password command to configure the local user name and password.

6.

Run the quit command to exit from the AAA view.

l Configure non-authentication. 1.


2.


3.

Run the authentication-mode none command to configure non-authentication.

Step 3 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 if 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 HUAWEI NetEngine80E/40E Router 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 NE80E/40E have reached the maximum. Log in to the NE80E/40E 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 userinterface maximum-vty command to view the allowed maximum number of login users.

Issue 02 (2011-09-10)


8



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 + 39 VTY 5 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 NE80E/40E 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

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 NE80E/40E. This means that to allow a client to telnet to the NE80E/40E, 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 or to none by running the authentication-mode none command.

Issue 02 (2011-09-10)


9


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 NE80E/40E, 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. 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.

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 NE80E/40E

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

Prerequisite Figure 2-6 Networking diagram of logging in to the NE80E/40E by using SSH

network

SSH Client

SSH Server

Before logging in to the NE80E/40E by using SSH, complete the following tasks: l

Ensure that the NE80E/40E is working properly.

l

Log in to the NE80E/40E by using the console interface and configure an IP address for each interface on the NE80E/40E.

l

Ensure that there is a direct or reachable route between the SSH client and the NE80E/ 40E. NOTE

Perform the following configurations on the NE80E/40E that serves as the SSH server:

Procedure Step 1 Configure the NE80E/40E to generate a local key pair. 1. Issue 02 (2011-09-10)

Run the system-view command to enter the system view. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

10


2.


Run the rsa local-key-pair create command to configure the NE80E/40E to generate a local RSA key pair.

Step 2 Configure a VTY user interface to support SSH. 1.


2.


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 3 Run the ssh user user-name command in the system view to create an SSH user. Step 4 Run the ssh user username authentication-type { all | password | password-rsa | rsa } command in the system view to configure an authentication mode for SSH users. Perform one of the following operations as needed: l Configure password authentication. – Run the ssh user user-name authentication-type password command to configure password authentication. – Run the ssh authentication-type default password command to configure default password authentication. If local authentication or HWTACACS authentication is used, default password authentication will be preferable for SSH users when the user number is great, which can simplify configurations. l 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 key-name command to enter the public key view.

3.

Run the public-key-code begin command to enter the public key edit view.

4.

Enter hex-data to edit the public key.

5.

Run the public-key-code end command to exit from the public key edit view. If illegal hexadecimal data is entered, no key will be generated after the peer-public-key end command is run. If key-name specified in Step b has been deleted in another window, the system will display a message indicating that the key does not exist and return to the system view directly after you run the peer-public-key end command.

6.

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

7.

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

Step 5 In password or RSA authentication mode, create a local user with the SSH user name in the AAA view. 1. Issue 02 (2011-09-10)

Run the aaa command in the system view to enter the AAA view. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

11



2.

Run the local-user user-name password { cipher| simple } password command to configure the local user name and password.

3.

Run the local-user user-name level level command to configure the priority of the local user.

4.

Run the local-user user-name service-type ssh command to configure the local user access type.

5.

Run the quit command to exit from the AAA view.

Step 6 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 7 Run the stelnet server enable command in the system view to enable STelnet. ----End

Commissioning Results Log in to the NE80E/40E by using SSH. This section describes only the SSH login by using the PuTTY program. In this example, the IP address of the NE80E/40E is 192.168.1.1; the SSH user name is client001; the password is huawei. 1.

As shown in the following figure, set the IP address of the NE80E/40E to 192.168.1.1 and the login protocol to SSH. Figure 2-7 Login by using the PuTTY program

Issue 02 (2011-09-10)


12


2.


Enter the user name client001 and the password huawei. Figure 2-8 Login by using the PuTTY program

Troubleshooting If the SSH login fails, perform the following operations: 1.

Check that the 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 HUAWEI NetEngine80E/40E Router 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

Issue 02 (2011-09-10)

:1.99 :60 seconds :0 hours :3 times :Disable :Disable


13



The command output shows that the SFTP and STelnet servers are not enabled. A user can log in to the NE80E/40E by using SSH only after SSH services are enabled on the NE80E/ 40E. Run the following command to enable the SSH server. system-view [HUAWEI] sftp server enable [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 [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 NE80E/40E 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] [HUAWEI] [HUAWEI] [HUAWEI]

ssh ssh ssh ssh

user user user user

abc abc authentication-type all abc service-type all abc sftp-directory cfcard:/ssh

Configure the same SSH user in the AAA view and set the authentication service type. [HUAWEI] aaa [HUAWEI] local-user abc password simple abc-pass [HUAWEI] local-user abc 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] local-user abc password simple abc-pass [HUAWEI] local-user abc service-type ssh

6.

Check whether login users on the NE80E/40E have reached the maximum. Like Telnet users, SSH users use VTY user interfaces when logging in to the NE80E/ 40E. 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 NE80E/ 40E.

Issue 02 (2011-09-10)


14



Log in to the NE80E/40E by using the console interface. Then, run the display users command to check whether 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 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 + 39 VTY 5 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 NE80E/40E 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 NE80E/40E by using SSH. This means that to allow a client log in to the NE80E/40E 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. 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 NE80E/40E

Issue 02 (2011-09-10)


15


3 Checking the Hardware

3

Checking the Hardware

About This Chapter This section describes how to check power supply, fans, boards, and interfaces to prepare for NE80E/40E commissioning. 3.1 Checking the Software Version You need to check whether the used software version meets deployment requirements. 3.2 Checking the Health Status of the NE80E/40E You need to check whether the current status of the NE80E/40E meets the deployment requirement. 3.3 Checking the Board Registration Status You need to check whether all boards are properly installed and work normally. 3.4 Checking the Fan Status You need to check whether fans work properly. 3.5 Checking the Power Status You need to check whether power modules work properly. 3.6 Checking System Time You need to check system time to ensure that the NE80E/40E works with other devices coordinately. 3.7 Checking the Interface Status You need to check whether interfaces are in the normal state. 3.8 Checking Alarm Information You need to check whether faults have occurred and important alarm information have been generated on the NE80E/40E. 3.9 Checking the Voltage of Each Board You need to check the voltage of each board. 3.10 Checking the Temperature of Each Board You need to check the temperature of each board.

Issue 02 (2011-09-10)


16



3.1 Checking the Software Version You need to check whether the used software version meets deployment requirements.

Prerequisite 2 Logging In to the NE80E/40E is complete.

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) software, Version 5.90 (NE40E&80E V600R003C00SPC300) Copyright (C) 2000-2010 Huawei Technologies Co., Ltd. HUAWEI NetEngine 40E uptime is 0 day, 10 hours, 15 minute NE40E version information:

---- More ---If the version displayed in boldface in the preceding information on the NE80E/40E 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: SlaveBoard: 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:/V600R003C00SPC300.cc cfcard:/V600R003C00SPC300.cc cfcard:/V600R003C00SPC300.cc cfcard:/vrpcfg.zip cfcard:/vrpcfg.zip cfcard:/paf-V600R003C00SPC300.txt cfcard:/paf-V600R003C00SPC300.txt cfcard:/license-V600R003C00SPC300.txt cfcard:/license-V600R003C00SPC300.txt cfcard:/patch.bat cfcard:/patch.bat cfcard:/V600R003C00SPC300.cc cfcard:/V600R003C00SPC300.cc cfcard:/V600R003C00SPC300.cc cfcard:/vrpcfg.zip cfcard:/vrpcfg.zip cfcard:/paf-V600R003C00SPC300.txt cfcard:/paf-V600R003C00SPC300.txt cfcard:/license-V600R003C00SPC300.txt cfcard:/license-V600R003C00SPC300.txt cfcard:/patch.bat cfcard:/patch.bat

If the names of system software and configuration files, displayed in boldface in the preceding information, for the next startup are consistent with that required for deployment, go on with the subsequent commissioning. ----End

Troubleshooting If the software version does not meet the deployment requirement, it needs to be upgraded. Issue 02 (2011-09-10)


17



NOTE

Before upgrading the software version, contact Huawei technical support personnel or visit http:// support.huawei.com to download 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.

3.2 Checking the Health Status of the NE80E/40E You need to check whether the current status of the NE80E/40E meets the deployment requirement.


Procedure Step 1 Run the display health command to view the health status of the NE80E/40E. display health -----------------------------------------------------------Slot CPU Usage Memory Usage (Used/ Total) -----------------------------------------------------------18 MPU(Master) 16% 43% 438MB/ 1008MB 2 LPU 12% 16% 164MB/ 988MB 6 LPU 26% 27% 275MB/ 988MB 11 LPU 4% 15% 152MB/ 988MB 16 LPU 14% 27% 275MB/ 988MB 19 SFU 18% 48% 13MB/ 28MB 20 SFU 18% 48% 13MB/ 28MB 21 SFU 18% 48% 13MB/ 28MB 22 SFU 16% 48% 13MB/ 28MB 17 MPU(Slave) 9% 34% 350MB/ 1008MB ------------------------------------------------------------

If the CPU usage and memory usage of the boards on the NE80E/40E 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 You need to check whether all boards are properly installed and work normally.

Prerequisite 2 Logging In to the NE80E/40E is complete. Issue 02 (2011-09-10)


18



Procedure Step 1 Run the display device [ pic-status | slot-id ] command to view information about the components installed on the NE80E/40E. If [ pic-status | slot-id ] is specified, the command will display information about the Physical Interface Cards (PICs) on all LPUs and information about a specified slot for the LPU, MPU, SFU, power module, or fan module. display device NE40E's Device status: Slot # Type Online Register Status Primary --------------------------------------------------------------------------2 LPU Present Registered Normal NA 3 LPU Present Registered Normal NA 4 LPU Present Registered Normal NA 6 LPU Present Registered Normal NA 9 MPU Present Registered NA Master 10 MPU Present Registered Normal Slave 11 SFU Present Registered Normal NA 12 SFU Present Registered Normal NA 13 SFU Present Registered Normal NA 14 SFU Present Registered Normal NA 15 CLK Present Registered Normal Master 16 CLK Present Registered Normal Slave 18 PWR Present Registered Normal NA 19 FAN Present Registered Normal NA 20 FAN Present Registered Normal NA 21 LCD Present Registered Normal NA ---------------------------------------------------------------------------

Pay attention to the Register and Status fields in the displayed information. l Register field: indicates whether a component is successfully registered. The field value can be NA, Registered, or Unregistered. NA indicates that the component must be used during the NE80E/40E startup. Registered indicates that a component is successfully registered. Unregistered indicates that a component is not registered. l Status field: indicates the component status. The field value can be Normal or Abnormal. If the Register field values are Registered or NA and the Status field values are Normal, as shown by the characters in boldface in the preceding displayed information, go on with the subsequent commissioning. ----End

Troubleshooting If the board is not registered, perform the following operations: 1.

Check that the start-up time of the board has expired. The time required for a board to complete registration after it is powered on is called the start-up time. Normally, an LPU can complete the start-up process within 5 minutes. If the system software and related files need to be updated, an LPU can complete the start-up process within 10 minutes. Normally, an SFU can complete the start-up process within 2 minutes. If the system software and related files need to be updated, an SFU can complete the start-up process within 5 minutes. Wait until the start-up time expires. If the board is still unregistered when the start-up time expires, go to Step 2.

2. Issue 02 (2011-09-10)

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

19



Supported board types vary with system software versions. For the types of boards that are supported by this software version, see the chapter titled "Boards" in the HUAWEI NetEngine80E/40E Router Hardware Description. If the board type is supported by this system software version but the board cannot be registered, go to Step 3. 3.

Check that the board has been powered on. Run the power on slot ? command in the user view. If "" is displayed, all boards have been powered on. If the slot number of the board is displayed, the board is not 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 Step 4.

4.

Upgrade the EPLD of the board. Run the upgrade lpu by-testbus slot-id startup mbus_epld, upgrade lpu by-testbus slot-id startup fad_epld, and upgrade lpu by-testbus slot-id startup lpu_epld commands in the user view to upgrade the EPLD of the LPU. Run the upgrade sfu by-testbus slot-id startup mbus_epld, upgrade sfu by-testbus slotid startup sfu_epld1, and upgrade sfu by-testbus slot-id startup sfu_epld2 commands in the user view to upgrade the EPLD of the SFU. If the board still cannot be registered after the EPLD is upgraded, go to Step 5.

5.

Upgrade the basic BootROM and advanced BootROM of the board. Run the upgrade lpu by-testbus slot-id startup lpu_bootrom, upgrade lpu by-testbus slot-id startup lpu_bootload, upgrade lpu by-testbus slot-id startup fad_bootrom, and upgrade lpu by-testbus slot-id startup fad_bootload commands in the user view to upgrade the basic BootROM and advanced BootROM of an LPU. Run the upgrade sfu by-testbus slot-id startup sfu_bootrom and upgrade sfu bytestbus slot-id startup sfu_bootload commands in the user view to upgrade the basic BootROM and advanced BootROM of the concerned SFU. If the board still cannot be registered after the upgrade, go to Step 6.

6.

If a new board cannot be registered, remove the board and then install it again. If the board still cannot be registered, go to Step 7.

7.


3.4 Checking the Fan Status You need to check whether fans work properly.

Prerequisite 2 Logging In to the NE80E/40E is complete. Issue 02 (2011-09-10)


20



Procedure Step 1 Run the display fan command to check the fan status. display fan Slotid : 19 Present : YES Registered: YES Status : AUTO FanSpeed : [No.]Speed [1]45% Slotid : 20 Present : YES Registered: YES Status : AUTO FanSpeed : [No.]Speed [1]45%

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 details, see display fan.

3.5 Checking the Power Status You need to check whether power modules work properly.


Procedure Step 1 Run the display power command to check the power status. display power No Present mode State Num ------------------------------------------------------------------------------17 Yes DC Normal 1 18 Yes DC Normal 1 Power monitor cable state: Plug

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 details, see display power. Issue 02 (2011-09-10)


21



3.6 Checking System Time You need to check system time to ensure that the NE80E/40E works with other devices coordinately.


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 NE80E/40E 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 You need to check whether interfaces are in the normal state.


Procedure Step 1 Run the display interface brief [ main ] command to view brief information about all interfaces on the NE80E/40E. 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 (2011-09-10)


22



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% GigabitEthernet3/0/0 up up 50% GigabitEthernet3/0/3 *down down 40% GigabitEthernet3/0/1 up up 0% GigabitEthernet3/0/2.1 up up 0% Ip-Trunk1 up up 0%

OutUti 7% 60% 30% 0% 0% 0%

inErrors 12 23 0 0 0 0

outErrors 0 125 0 0 0 0

Ensure that the physical status and protocol status are Up. ----End

Troubleshooting If the physical status is Down, perform the following operations: 1.

Run the display this command on both the local and remote interfaces to check whether they have been shut down. If either one of them or both of them have been shut down, run the undo shutdown command in the interface view. After that, run the display this interface command to check whether the interfaces have gone Up.

2.

At this step, Ethernet interfaces and non-Ethernet interfaces are handled differently. l If Ethernet interfaces are used for connection, check that the rate and duplex mode have been configured on the peer device. Then, set the same rate and duplex mode on the local interface as that on the peer device. After that, run the display this interface command to check whether the interface status is Up. The available commands are as follows: – Run the duplex { full | half | auto } command to configure the half-duplex mode on an Ethernet interface. – Run the speed { 10 | 100 | 1000 | auto } command to configure the rate on an Ethernet interface. l If non-Ethernet interfaces are used for connection, skip this step.

3.

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

For details on how to check optical power of optical interfaces, see 4.7 Checking the Optical Power of Interfaces.

Issue 02 (2011-09-10)


23



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

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.

5.

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 NE80E/ 40E.

6.

Contact Huawei technical support personnel.

3.8 Checking Alarm Information You need to check whether faults have occurred and important alarm information have been generated on the NE80E/40E.


Procedure Step 1 Run the display alarm { slot-id | all } command to view all alarms on the NE80E/40E to determine if faults have occurred on the NE80E/40E. 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] [ | count ] [ | { begin| include| exclude} regularexpression] 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 2", RelativeResource="S FP", ReasonDescription="LPU 2 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 severitys are 3 or higher. ----End Issue 02 (2011-09-10)


24



3.9 Checking the Voltage of Each Board You need to check the voltage of each board.


Procedure Step 1 Run the display voltage[ [ lpu | mpu | sfu ] slot slot-id [ pic pic-id ] ] command to view the status of the voltage sensor on each board. display voltage SlotID2 : SlotID: 2 Base-Board, Unit: Volt, Slot2 PCB I2C Addr Chl Status Required LowAlmThreshold HighAlmThreshold Vol Ratio Major Fatal Major Fatal ------------------------------------------------------------------------------FADB 1 0 0 NORMAL 1.50 1.20 1.05 1.80 1.95 1.50 1.00 FADB 1 0 1 NORMAL 1.80 1.44 1.26 2.16 2.34 1.85 1.00 FADB 1 0 2 NORMAL 2.50 2.00 1.75 3.00 3.25 2.77 0.68 FADB 1 0 6 NORMAL 5.00 4.05 3.55 6.07 6.57 5.02 0.38 LPUA 1 0 3 NORMAL 1.30 1.04 0.91 1.56 1.69 1.33 1.00 LPUA 1 0 4 NORMAL 1.30 1.04 0.91 1.56 1.69 1.32 1.00 LPUA 1 0 5 NORMAL 2.50 2.00 1.75 3.00 3.25 2.53 0.76 EAGF 1 3 0 NORMAL 1.80 1.62 1.44 1.98 2.16 1.89 1.00 EAGF 1 3 1 NORMAL 2.50 2.25 2.00 2.75 3.00 2.50 0.76 EAGF 1 3 2 NORMAL 3.30 3.00 2.67 3.67 4.00 3.39 0.58 EAGF 1 3 6 NORMAL 5.00 4.55 4.05 5.57 6.07 5.02 0.38

Pay attention to the values of the fields displayed in boldface. The Required field indicates the ideal voltage. The Vol field indicates the current voltage. The Low_Alam_Threshold Major field indicates the threshold of a low voltage for a minor alarm. If the voltage is below this threshold, a minor alarm will be generated. The Low_Alam_Threshold Fatal field indicates the threshold of a low voltage for a critical alarm. If the voltage is below this threshold, the NE80E/40E may work abnormally or be damaged. The High_Alam_Threshold Major field indicates the threshold of a high voltage for a minor alarm. If the voltage is higher than this threshold, a minor alarm will be generated. The High_Alam_Threshold Fatal field indicates the threshold of a high voltage for a critical alarm. If the voltage is higher than this threshold, the NE80E/40E may work abnormally or be damaged. If the displayed value of the Vol field is between the value of the Low_Alam_Threshold Major field and the value of the High_Alam_Threshold Major field, the board voltage is normal. Then, go on with the subsequent commissioning. ----End

Troubleshooting If the board voltage is below the lower voltage threshold, perform the following operations: 1.

Check that the voltage of power supply is sufficient.

2.

Replace the board and check that the board voltage increases above the lower voltage threshold.

Issue 02 (2011-09-10)


25


3.


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

If the board voltage is higher than the upper voltage threshold, perform the following operations: 1.

Replace the board and check that the board voltage drops below the upper voltage threshold.

2.


3.10 Checking the Temperature of Each Board You need to check the temperature of each board.


Procedure Step 1 Run the display temperature[ [ lpu | mpu | sfu ] slot slot-id [ pic pic-id ] ] command to view the temperature status on each board. display temperature SlotID2 Base-Board, Unit:C, Slot2 PCB I2C Addr Chl Status Minor Major Fatal Adj_speed Temp TMin Tmax (C) ----------------------------------------------------------------LPUF 1 1 0 NORMAL 70 80 90 60 70 36 LPUF 1 2 0 NORMAL 60 70 80 50 60 33 LPUF 1 4 0 NORMAL 70 80 90 60 70 35 LPUF 1 5 0 NORMAL 80 90 100 70 80 39 LPUF 1 6 0 NORMAL 70 80 90 60 70 38 LPUF 2 76 1 NORMAL 90 96 102 80 90 39 LPUF 2 76 2 NORMAL 90 96 102 80 90 40 TCMB 1 3 0 NORMAL 70 80 90 60 70 34 TCMB 1 7 0 NORMAL 60 70 80 50 60 31

Pay attention to the values of the fields displayed in boldface. The Temp(C) field indicates the current temperature. The Minor field indicates the threshold of a high temperature for a minor alarm. The Major field indicates the threshold of a high temperature for a major alarm. The Fatal field indicates the threshold of a high temperature for a critical alarm. If the board temperature reaches or exceeds the value of the Fatal field, the NE80E/40E may work abnormally or be damaged. If the displayed value of the Temp(C) field is lower than that of the Minor field, the board temperature is normal. Then, go on with the subsequent commissioning. ----End

Troubleshooting If the board temperature exceeds the threshold, perform the following operations: 1.

Check whether fans are faulty and replace any faulty fans.

2.

Check whether the air filter is clogged. If it is clogged, clean it.

Issue 02 (2011-09-10)


26



3.

Check whether the ambient temperature is too high. If the ambient temperature is too high, lower the temperature in the equipment room.

4.

If the board temperature is still high after the preceding operations, it is due to the high chip temperature. In this case, no action is required or contact Huawei technical support personnel.

Issue 02 (2011-09-10)


27


4 Commissioning the Link Layer

4

Commissioning the Link Layer

About This Chapter This section describes how to commission the link layer when the NE80E/40E is connected to other routers or transport devices. 4.1 Checking Ethernet Interfaces This section describes how to check the link layer on Ethernet interfaces. 4.2 Checking POS Interfaces This section describes how to check the link layer on POS interfaces. 4.3 Checking CPOS Interfaces This section describes how to check the link layer on CPOS interfaces. 4.4 Checking E-Carrier and T-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.5 Checking ATM Interfaces This section describes how to check the link layer on ATM interfaces. 4.6 Checking FR Interfaces This section describes how to check the link layer on Frame Relay (FR) interfaces. 4.7 Checking the Optical Power of Interfaces You need to check whether the optical power of SFP optical modules meets requirements. If the output optical power of SFP optical modules on the boards of the NE80E/40E does not meet requirements, packets will be lost and communication will be interrupted on the network layer.

Issue 02 (2011-09-10)


28



4.1 Checking Ethernet Interfaces This section describes how to check the link layer on Ethernet interfaces.

Prerequisite 3 Checking the Hardware is complete and the NE80E/40E works properly.

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/0/0 up enable half -GigabitEthernet2/0/0 up disable full -GigabitEthernet2/0/1 up disable full -GigabitEthernet3/0/2 up enable full --

Bandwidth

InUti

OutUti

100M

0%

0%

1000M

0.01%

0.01%

1000M

0%

0%

1000M

0.01%

0.01%

In normal situations, the physical status of interfaces are up, as shown by the characters displayed in boldface. Step 2 Run the display interface command to view the MTU, IP address, mask, rate, and operation mode of an Ethernet interface. For example: display interface gigabitethernet 2/0/0 GigabitEthernet2/0/0 current state : UP Line protocol current state : UP Last line protocol up time : 2010-02-09 04:26:01 Description:HUAWEI, Quidway Series, GigabitEthernet2/0/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 00e0-fc7d-a49d The Vendor PN is FTRJ8519P1BNL-HW The Vendor Name is FINISAR CORP. Port BW: 1G, Transceiver max BW: 1G, Transceiver Mode: MultiMode WaveLength: 850nm, Transmission Distance: 550m Rx Power: -6.72dBm, Tx Power: -6.28dBm 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 : 2010-03-21 15:35:04 Last physical down time : 2010-03-21 15:35:04 Current system time: 2010-02-10 23:49:52 Statistics last cleared: never Last 300 seconds input rate: 240 bits/sec, 0 packets/sec Last 300 seconds output rate: 88 bits/sec, 0 packets/sec Input: 4763528 bytes, 61864 packets Output: 1718640 bytes, 5208 packets Input:

Issue 02 (2011-09-10)


29



Unicast: 0 packets, Multicast: 30932 packets Broadcast: 30932 packets, JumboOctets: 0 packets CRC: 0 packets, Symbol: 0 packets Overrun: 0 packets, LongPacket: 0 packets Jabber: 0 packets, Alignment: 0 packets Fragment: 0 packets, Undersized Frame: 0 packets RxPause: 0 packets Output: Unicast: 0 packets, Multicast: 5208 packets Broadcast: 0 packets, JumboOctets: 0 packets Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets System: 0 packets, Overruns: 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 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. – Check that the auto-negotiation modes on the local and peer interfaces are consistent. If they are inconsistent, run the duplex command to make the two interfaces use the same duplex mode. – 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.

Issue 02 (2011-09-10)


30



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.

Run the loopback command to check that the fiber between the local and peer ends is not damaged. If the physical layer on the local interface is Up after the loopback local command is run, the local interface is normal. If the physical layer on the peer interface is Up after the loopback remote command is run, the peer interface is normal. It indicates that the fiber between the local and peer interfaces is damaged. Replace the fiber.

5. l


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

Check that the local end is correctly connected to the peer end. Observe the Link indicator on the LPU 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 addresses.

4.

Check that the link layer protocols on the local and peer ends are consistent. Reliable communication between two Ethernet devices is available only when they use the same link layer protocol.

5.


4.2 Checking POS Interfaces This section describes how to check the link layer on POS interfaces.


Procedure Step 1 Run the display interface brief command to view brief information about POS interfaces, including the physical status, link layer protocol status, bandwidth usage, and statistics about incorrect packets. display interface brief | include Pos PHY: Physical *down: administratively down ^down: standby (l): loopback (s): spoofing (b): BFD down (e): EFM down (d): Dampening Suppressed InUti/OutUti: input utility/output utility Interface PHY Protocol InUti OutUti inErrors outErrors Pos1/0/0 up up 0.01% 0.01% 3795064053 0

Issue 02 (2011-09-10)


31

HUAWEI NetEngine80E/40E Router Commissioning Guide Pos1/0/1 Pos1/0/2 Pos1/0/3


down down down down down down

0% 0% 0%

0% 0% 0%

343911292 343913408 343915353

0 0 0

This command can quickly display the physical status and link layer protocol status of all POS interfaces on the NE80E/40E. Step 2 Run the display interface pos command to view the physical status, link layer protocol status, clock mode on a POS interface. For example: display interface pos 1/0/0 Pos1/0/0 current state : UP Line protocol current state : UP Last line protocol up time : 2011-03-12 22:16:41 Description:HUAWEI, Quidway Series, Pos1/0/0 Interface Route Port,The Maximum Transmit Unit is 4470, Hold timer is 10(sec) Internet Address is 1.0.0.1/24 Link layer protocol is PPP LCP opened, IPCP opened The Vendor PN is FTRJ8519P1BNL-HW The Vendor Name is FINISAR CORP. Port BW: 2.5G, Transceiver max BW: 2.5G, Transceiver Mode: SingleMode WaveLength: 1310nm, Transmission Distance: 5km Rx Power: -5.51dBm, Tx Power: -6.00dBm Physical layer is Packet Over SDH, Scramble enabled, clock master, CRC-32, loopback: none Flag J0 "NetEngine " Flag J1 "NetEngine " Flag C2 22(0x16) 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-03-12 22:16:35 Last physical down time : 2011-03-12 22:16:34 Current system time: 2011-03-12 22:16:43 SDH alarm: section layer: none line layer: none path layer: none SDH error: section layer: B1 0 line layer: B2 0 REI 0 path layer: B3 0 Statistics last cleared:2010-01-08 17:00:08 Last 30 seconds input rate 22026736 bits/sec, 23333 packets/sec Last 30 seconds output rate 23520304 bits/sec, 23333 packets/sec Input: 800011 packets, 94402078 bytes Input error: 0 shortpacket, 0 longpacket, 0 CRC, 0 lostpacket Output: 800005 packets, 100801469 bytes Output error: 0 lostpackets Output error: 0 overrunpackets, 0 underrunpackets Input bandwidth utilization : 0.01% Output bandwidth utilization : 0.01%

As shown by the characters displayed in boldface, in normal situations, the physical status and link layer protocol status on a POS interface are UP; link configurations on the local POS interface are the same as that on the peer POS interface; no alarms and errors are displayed. If the alarm count and error count are not 0, run the command several times to check whether the counts increase. Or, run the reset counters interface command to clear the statistics and then run the command several times. Step 3 Run the ping command to test POS 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 Reply from 192.168.1.2: bytes=56 Sequence=2 ttl=255 time=1 Reply from 192.168.1.2: bytes=56 Sequence=3 ttl=255 time=1 Reply from 192.168.1.2: bytes=56 Sequence=4 ttl=255 time=1

Issue 02 (2011-09-10)


ms ms ms ms

32



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


Troubleshooting If the physical status of a POS interface does not go Up after it is connected, perform the following operations: 1.

Check that the local and peer POS interfaces are enabled, the input and output optical power of the interfaces are normal, and there are no SDH alarms. Run the display interface pos [ interface-number ] command. l If the value of the current state field is Administratively down, the POS interface is not enabled. Run the undo shutdown command in the interface view. l If the output optical power is not within the allowed range, replace the optical module. l If the input optical power is smaller than the receiver sensitivity, adjust the link or replace the peer optical module. l If the values of the fields under the SDH alarm field are not none and B1, B2, and B3 error code counts displayed under the SDH error fields increase, note the following points: – If B1, B2, and B3 error code counts all increase, check the direct link between the optical modules as well as these modules on the two ends. If the link is a WDM link, ensure that it is stable. – If only the B3 error code count increases, check the link directly connecting the peer device and an SDH device because this problem often occurs when a routing device is connected to an SDH device. If the link between the concerned SDH devices is a WDM link, you also need to check the entire WDM link to ensure stable transmission. If the fault persists, go to Step 2.

2.

Check that the fiber and optical modules are properly installed. An optical module or a fiber connector has a fastener. If you hear a click when installing the fiber or an optical module, the fiber or optical module is properly installed. If the fault persists, go to Step 3.

3.

Check that the fiber is connected to the correct transmit optical module and receive optical module. Remove the fiber and connect it to a different module of the original interface on each end (for example, if the fiber is connected to the transmit optical module of an interface on the local end, remove it and then connect the fiber to the receive optical module of that interface on the local end). If the fault is not rectified, restore the original fiber connection. If the fault persists, go to Step 4.

4.

Use a fiber to perform local loopback. Use a good fiber to connect the transmit and receive optical modules of the local interface.

Issue 02 (2011-09-10)


33



l If the physical layer is Up and SDH alarms are all cleared and B1, B2, and B3 error code counts do not increase on the interface, the local optical modules and the board where the interface resides work properly. You need to check the link and the peer device. l If the physical layer is not Up, the local optical modules or the board where the modules reside works abnormally. Switch the services of the board or the concerned interface to another board and then replace the optical modules or the board to see if the fault will be rectified. NOTE

Before using a fiber to perform local loopback, run the clock master command to set the clock mode of an interface to master.

If the fault persists, go to Step 5. 5.


4.3 Checking CPOS Interfaces This section describes how to check the link layer on CPOS interfaces.


Procedure Step 1 Run the display controller cpos command to check the status of a CPOS interface. For example: display controller cpos 1/0/0 Cpos1/0/0 current state : UP Description : Cpos1/0/0 Interface The Vendor Name is AGILENT The Vendor PN is QFCT-5736TP Port BW: 155M, Transceiver max BW: 155M, Transceiver Mode: SingleMode WaveLengh: 1310nm, Transmission Distance: 15km Physical layer is Packet Over SDH clock master, Multiplex AU-4, loopback none TX:Flag J0: "NetEngine ", Flag J1: "NetEngine ", Flag C2: 2(0x2) RX:Flag J0: "NetEngine ", Flag J1: "NetEngine ", Flag C2: 2(0x2) section layer: alarm: none error: B1 0 line layer: alarm: none error: B2 0 REI 0 path layer: alarm: none error: B3 0 REI 0 The setted port-tx-enabling delay time is: 0 ms The remanent time of enabling port-tx is: 0 ms

As shown by the characters displayed in boldface, the CPOS interface status is UP when the CPOS interface is correctly configured, and no alarms or errors are displayed. If the alarm count and error count are not 0, run the command several times to check whether the counts increase. Or, clear the statistics and then run the command several times. Issue 02 (2011-09-10)


34



Step 2 Run the display interface serial command to view the operation status of and statistics on the serial interface. For example: display interface serial 1/0/0/0:0 Serial1/0/0/0:0 current state : Up Line protocol current state : Up Description:HUAWEI, Quidway Series, Serial1/0/0/0:0 Interface Route Port,The Maximum Transmit Unit is 1500, Hold timer is 10(sec) Derived from CPOS 1/0/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 link layer protocol status of the serial interface are Up when the serial interface channelized from a CPOS 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 CPOS 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


Troubleshooting If serial interfaces on the two ends of a link cannot communicate with each other after the interfaces are configured, perform the following operations: 1.

Issue 02 (2011-09-10)

Check the physical status of the CPOS interfaces on both ends.


35



(1) Check the type of fiber connecting the CPOS interfaces and whether the fiber is correctly installed. (2) If the fiber is correctly and properly installed, run the undo shutdown command and then the display this interface command on the local serial interface. You can see that the physical status of the interface is Up. (3) If the physical status of the interface is Down, run the clock master command and then the loopback local command on the CPOS interface on each end. If the physical status of the interface on each end is Up, the fiber may be faulty. If the physical status of the interface on either end is still Down, the board where the interface resides may be faulty. In this case, seek technical support. 2.

Check that the link layer protocol configurations on both ends of the link are consistent. (1) Run the display this interface command on the serial interface on each end to view the configured link layer protocol. If PPP is configured on one end and HDLC is configured on the other end, change the link layer protocol configurations to ensure consistency on both ends. (2) Check whether the MTUs on the serial interfaces on both ends are the same. Run the display interface interface-type interface-number command on the serial interface on each end to view the MTU. If the MTUs on the serial interfaces on the two ends are not the same, run the mtu command on one end to ensure MTU consistency. If the fault persists, proceed with the following operations. If the link layer protocol is HDLC, go to Step 3. If the link layer protocol is PPP, go to Step 4.

3.

Check that the HDLC configuration is correct. (1) Check whether IP address unnumbered is configured on the serial interfaces on both ends. Run the display this command on the serial interface on each end to check whether the ip address unnumbered interface interface-type interface-number command has been configured. If that command has been configured, ensure that the IP address borrower can learn the route to its peer. Otherwise, the ping operation will fail. (2) Check whether the same hold time is configured on the two ends. Run the display interface interface-type interface-number command on the serial interface on each end to view the value of the hold timer field. If different values of the hold timer field are configured on the two ends, run the timer hold command on one end to change the field value and ensure value consistency. If the fault persists, contact Huawei technical support personnel.

4.

Check that PPP works properly between the serial interfaces on the two ends. Verify that IP addresses are correctly configured for the serial interfaces on the two ends. Then, run the display this interface command on the serial interface on each end. If the command output shows that the link layer protocol is Down, perform the following operations to find the reason why PPP is not started: (1) Check whether Link Control Protocol (LCP) negotiation goes smoothly. LCP negotiation is the first phase of the setup of a PPP connection. If LCP negotiation between the two ends succeeds, a link will be set up and some basic link characteristics on the two ends will reach consistency.

Issue 02 (2011-09-10)


36



Run the display this interface command on the serial interface on either end. The command output shows the LCP negotiation status. If the status is opened, LCP negotiation is completed. Otherwise, LCP negotiation has not been completed yet. (2) Check whether Internet Protocol Control Protocol (IPCP) negotiation goes smoothly. IPCP negotiation follows successful LCP negotiation and authentication. In this phase, the IP addresses of serial interfaces are negotiated between the two ends. As a prerequisite, the serial interfaces on the two ends must be configured with IP addresses. Otherwise, the IPCP negotiation status cannot be checked. After confirming that the IP addresses configured on the serial interfaces on the two ends are correct, run the display this interface command on the serial interface on either end. The command output shows the IPCP negotiation status. If the status is opened, IPCP negotiation is completed. Otherwise, IPCP negotiation has not been completed yet. 5.

Check statistics on the serial interfaces on the two ends. If PPP is started after LCP and IPCP negotiation but the serial interfaces on the two ends still cannot ping each other, check statistics on the serial interfaces to find if the transmission of other types of packets is faulty. NOTE

Authentication is required between LCP negotiation and IPCP negotiation, which can be Password Authentication Protocol (PAP) authentication or Challenge Handshake Authentication Protocol (CHAP) authentication. If authentication fails, the link is disconnected. It is supposed that no authentication is configured in the preceding steps. If authentication is configured in real-world situations, check that the user name and password of the authenticated are correct. In addition, to check that the authentication messages are correctly transceived, enable debugging and check the statistics on the interface.

6.

If the fault persists, contact Huawei technical support personnel.

4.4 Checking E-Carrier and T-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.


Procedure Step 1 Run the display controller e1 command to check the status of a CE1 interface. For example: display controller e1 1/0/0 E1 1/0/0 current state : UP Description : HUAWEI, Quidway Series, E1 1/0/0 Interface Physical layer is Packet Over NO-CRC4 clock master, linecode hdb3 , loopback none section layer: alarm: none line layer: alarm: none path layer: alarm: none The setted port-tx-enabling delay time is: 0 ms The remanent time of enabling port-tx is: 0 ms

Issue 02 (2011-09-10)


37



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 operation status of and statistics on the serial interface. For example: display interface serial 1/0/0/0:0 Serial1/0/0/0:0 current state : Up Line protocol current state : Up Description:HUAWEI, Quidway Series, Serial1/0/0/0:0 Interface Route Port,The Maximum Transmit Unit is 1500, Hold timer is 10(sec) Derived from CPOS 1/0/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 link layer protocol status of the serial interface are Up when the serial interface channelized from a CE1 interface is correctly configured. If the IP addresses of the serial interfaces on both ends of the link and routes are correctly configured, the network layer protocol status on the local serial interface is enabled. Step 3 Run the ping command to test CE1 link connectivity. For example: 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


Troubleshooting If E-carrier or T-carrier interfaces on both ends of a link cannot communicate with each other after the interfaces are configured, perform the following operations: Issue 02 (2011-09-10)


38


1.


Check that the physical layer is Up. (1) Run the display controller e1 command to view interface information on each end. If the physical status is displayed as Administratively Down, the shutdown command has been run on the interface. Run the undo shutdown command to enable the interface. If the physical status is displayed as Down, check the following items: l Fiber is properly connected to the local interface and the indicator for the interface is in a normal state. l Fiber is properly connected to the peer interface. Run the display this interface command in the interface view to check if the physical status of the peer interface is Administratively Down and if loopback is configured on the peer interface. l Interface configurations, such as the operation mode and line coding/decoding format, on the two ends are consistent, and the clock modes configured on the two ends are correct. (2) If the fault persists, run the link-protocol command in the CE1, serial, CT1, E3, or CT3 interface view to set the link layer protocol to HDLC and then run the loopback command in the CE1, CT1, E3, or CT3 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. (1) 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. (2) If the physical layer is Up, check whether correct IP addresses are configured for the interfaces on the two ends. (3) 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. (4) If the LCP negotiation status is opened and the IPCP negotiation status is not opened, IPCP negotiation has not been completed. IPCP negotiation is completed only when the IPCP negotiation status is opened.

3.

If the interfaces on the two ends of the link still cannot ping each other even if all configurations are correct, run the display interface serial command to view statistics on the interfaces and contact Huawei technical support personnel.

4.5 Checking ATM Interfaces This section describes how to check the link layer on ATM interfaces.


Issue 02 (2011-09-10)


39



Procedure Step 1 Run the display interface atm command to check the configurations, physical status, and link layer protocol status on an ATM interface. For example: display interface atm 1/0/0 Atm1/0/0 current state : UP Line protocol current state : UP Last line protocol up time: 2010-11-03, 17:24:24 Description : Atm1/0/0 Interface Route Port, The Maximum Transmit Unit is 1500 Internet protocol processing : disabled AAL enabled: AAL5, Maximum VCs: 2048 VCs on main-interface: 1 (Total VCs: 1) VPs on main-interface: 0 (Total VPs: 1 ) The Vendor Name is FINISAR CORP. , The Vendor PN is FTRJ1321P1BTL Transceiver BW: 2.5G, Transceiver Mode: Single Mode WaveLength: 1310nm, Transmission Distance: 5km Rx Optical Power: -24.95dBm, Tx Optical Power: -1.99dBm Physical layer is Packet Over SDH UBR: 1, CBR: 0, VBR: 0, USED BandWidth: 0Kbps VPI Max: 255, VCI Max: 2047 Scramble enabled, clock master, CRC-32, loopback: none Flag: J0 "NetEngine " Flag: J1 "NetEngine " Flag: C2 19(0x13) SDH alarm: section layer: OOF LOF LOS line layer: AIS path layer: AIS RDI SDH error: section layer: B1: 24 line layer: B2: 0 M1: 0 path layer: B3: 0 G1: 0 Statistics last cleared:never Send good cell: 0 cells Send idle cell: 25099462530 cells Receive idle cell: 0 cells Receive corrected cell: 0 Receive uncorrected cell: 97 Dropped receive cell: 0 cells Last dropped receive cell connection: 0/0 Last 30 seconds input rate: 0 bits/sec, 0 Packets/sec Last 30 seconds output rate: 0 bits/sec, 0 Packets/sec Input: 0 Bytes, 0 Packets Output: 0 Bytes, 0 Packets

As shown by the characters displayed in boldface, the physical status and link layer protocol status of the ATM interface are UP when the ATM interface is correctly configured. The command output also displays the frame format, clock mode, statistics interval, and whether scrambling is enabled. Step 2 Run the display atm map-info command to check whether information in the upper layer protocol mapping table is correct. display atm map-info Atm1/0/0, PVC 1/33, IP, State UP100.11.1.1, vlink 1 Atm1/0/0, PVC 2/101, ETH, Virtual-Ethernet1/0/0, UP

Step 3 Run the display atm pvc-info command to view PVC information. display atm pvc-info VPI/VCI |STATE|PVC-NAME |INDEX |ENCAP|PROT |INTERFACE --------|-----|----------------|--------|-----|-----|------------------0/40 |UP | |1 |SNAP |IP |Atm1/0/0 (UP) 0/60 |UP |to_adsl_a |2 |SNAP |ETH |Atm1/0/0.1 (UP) VPI/VCI |STATE|PVC-NAME |INDEX |ENCAP|PROT |INTERFACE --------|-----|----------------|--------|-----|-----|------------------1/10 |UP | |2 |SNAP |None |Atm2/0/0.1 (UP) 1/100 |UP | |1 |SNAP |IP |Atm2/0/0 (UP)

Issue 02 (2011-09-10)


40



Check the fields displayed in boldface in the preceding information to see if the PVC status is Up, the application mode is correct (in the PROT field, IP indicates IPoA, and ETH indicates IPoEoA), and the interface where the PVC resides is Up. Step 4 Run the display atm pvp-info command to view PVP information. display atm pvp-info VPI | STATE | PVP-NAME | INDEX | ENCAP | PORT | INTERFACE -------------------------------------------------------------------10 | UP | | 0 | AAL0 | None | Atm2/0/0.1(UP)

Check the fields displayed in boldface in the preceding information to see if the PVP status is Up, the application mode is correct (in the PROT field, IP indicates IPoA, and ETH indicates IPoEoA), and the interface where the PVP resides is Up. Step 5 Run the ping command to test ATM 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


Troubleshooting If ATM interfaces on the two ends of a link cannot communicate with each other after the interfaces are configured, perform the following operations: 1.

Enter the ATM interface view and run the display this interface command to check the physical status and link layer protocol status of the ATM interface on each end. If both status are Down, go to Step 2. If they are Up, go to Step 3.

2.

Check the physical status, link layer protocol status, and clock mode on the ATM interface on each end. l Check that fiber is correctly connected to the ATM interface. An ATM interface is connected to two fibers. One is used for signal receiving and connected to the receive optical module, and the other is used for signal transmission and connected to the transmit optical module. Ensure that the fiber connections are correct. If the fiber connections are incorrect, the physical status of the ATM interface is Down. If the fiber connections are correct, the Link indicator on the ATM interface is On. l The fiber connected to an ATM interface can be multimode fiber or single-mode fiber. If some ping packets are lost or the ping fails, check whether the ATM interfaces on the two ends are both multimode or single-mode interfaces. In most cases, a multimode interface and a single-mode interface that are directly connected can communicate with each other, but sometimes a great number of packets will be discarded or CRC errors will occur. l If two NE80E/40Es are directly connected, check whether the internal clocks are not enabled on two ATM interfaces. By default, one NE80E/40E uses a line clock. If the

Issue 02 (2011-09-10)


41



NE80E/40Es are directly connected or connected through a WDM device, run the clock master command on one of the NE80E/40Es to provide an internal clock. l If the physical status of the interface remains Down, contact Huawei technical support personnel. 3.

Check that the PVCs on the interfaces on both ends are the same. Since ATM interfaces use PVCs for communication, the PVCs on the interfaces on both ends must be the same. For IPoA, check that the protocol address mapping is correctly configured. If two NE80E/40Es are directly connected, the PVC mapped from the local to the peer IP address must be the same as the PVC mapped from the peer to the local IP address. Check whether the authentication configurations on both ends are the same for PPPoA.

4.

Check that the configurations and protocol types on the ATM interfaces on the two ends are the same. Check that the protocols (IPoA, PPPoA, IPoEoA, or PPPoEoA) over the PVCs on the ATM interfaces on the two ends are the same. If the routing protocol over ATM is Open Shortest Path First (OSPF), the mapping information configured on the ATM interfaces must contain broadcast. If the ATM interfaces on the two ends can use short packets, but not long packets, to ping each other, check whether the MTUs on the ATM interfaces are the same.

5.

If the ATM interfaces on the two ends still cannot communicate with each other, contact Huawei technical support personnel.

4.6 Checking FR Interfaces This section describes how to check the link layer on Frame Relay (FR) interfaces.


Procedure Step 1 Run the display fr interface command to view the physical status and link layer protocol status of FR interfaces and whether the FR interfaces are DTE or DCE interfaces. The command output also includes the type and link layer protocol status of the sub-interface. display fr interface Pos1/0/0, DCE, physical up, protocol up Pos1/0/0.1, point-to-point, protocol up

Check the information displayed in boldface in the preceding information to ensure that: l The working mode of the FR interface is correct. DTE indicates the working mode of the interface on the user side; DCE indicates the working mode of the interface on the network side. l The physical status and link layer protocol status are Up. l The network layer protocol is Up. l The sub-interface type is point-to-point. Step 2 Run the display fr map-info command to check the FR address mapping table. display fr map-info Map Statistics for interface Pos1/0/0 (DCE) DLCI 20, Point-to-Point DLCI, Pos1/0/0.1 created at: 2010/02/12 11:17:37, status: ACTIVE

Issue 02 (2011-09-10)


42



Check the information displayed in boldface in the preceding information to ensure that the configured Data-Link Connection Identifier (DLCI) is correct and dynamic address mapping works properly (ACTIVE). Step 3 Run the ping command to test FR 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


Troubleshooting If the physical status of an FR interface is Down, check whether the interface is properly connected to a cable. If the network layer protocol status is Down, check whether no DLCI is configured on the FR interface or its peer interface or the DLCIs configured on both ends are not the same. After changing the link layer configuration of an FR interface, run the shutdown command and then the undo shutdown command to restart the interface and make the configuration take effect. When configuring a DLCI on a sub-interface, you must shut down the sub-interface, configure a DLCI on the sub-interface, and then restart the sub-interface to make the configuration take effect.

4.7 Checking the Optical Power of Interfaces You need to check whether the optical power of SFP optical modules meets requirements. If the output optical power of SFP optical modules on the boards of the NE80E/40E does not meet requirements, packets will be lost and communication will be interrupted on the network layer.


Procedure Step 1 Run the display interface interface-type interface-number command to view the operation 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. In the following example, the display on a POS interface is used. Issue 02 (2011-09-10)


43



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 pos 1/0/0 Pos1/0/0 current state : UP Line protocol current state : UP Last line protocol up time : 2011-03-12 00:04:26 Description:HUAWEI, Quidway Series, Pos1/0/0 Interface Route Port,The Maximum Transmit Unit is 4470, Hold timer is 10(sec) Internet Address is 12.1.1.1/24 Link layer protocol is nonstandard HDLC The Vendor PN is FTRJ8519P1BNL-HW The Vendor Name is FINISAR CORP. Port BW: 2.5G, Transceiver max BW: 1G, Transceiver Mode: MultiMode WaveLength: 850nm, Transmission Distance: 550m Rx Power: -5.48dBm, Tx Power: -5.99dBm Physical layer is Packet Over SDH Scramble enabled, clock master, CRC-32, loopback: none Flag J0 "NetEngine " Flag J1 "NetEngine " Flag C2 22(0x16) 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-03-12 00:04:26 Last physical down time : 2011-03-12 00:04:26 Current system time: 2011-03-12 00:04:26 SDH alarm: section layer: none line layer: none path layer: none SDH error: section layer: B1 0 line layer: B2 0 REI 16777215 path layer: B3 0 REI 65535 Statistics last cleared:never Last 300 seconds input rate 1520 bits/sec, 0 packets/sec Last 300 seconds output rate 16 bits/sec, 0 packets/sec Input: 8112 packets, 4198302 bytes Input error: 0 shortpacket, 0 longpacket, 1 CRC, 0 lostpacket Output: 2173 packets, 56498 bytes Output error: 0 lostpackets Output error: 0 overrunpackets, 0 underrunpackets Input bandwidth utilization : 0.01% Output bandwidth utilization : 0.01%

Check the information displayed in boldface 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 on the two ends against the "List of LPU Interface Attributes" to determine if the output optical power is within the allowed range. NOTE

For details about the "List of LPU Interface Attributes", see the attachment. The output optical power of the local optical module must meet the following requirements: l The minimum output optical power must be higher than the receiver sensitivity of the optical module. Otherwise, the peer end cannot receive signals. l The maximum output optical power must be lower than the overload power of the optical module. Otherwise, the optical module may be damaged.

----End

Issue 02 (2011-09-10)


44



Troubleshooting If the output optical power of an optical module is beyond the allowed range, replace the optical module.

Issue 02 (2011-09-10)


45


5

5 Commissioning Services and Protocols

Commissioning Services and Protocols

About This Chapter This section describes how to commission services and protocols, especially routing protocols, tunnel services, VPN services, and BFD functions used when the NE80E/40E is connected to other routers or transport devices.

Service and Protocol Commissioning Figure 5-1 Flowchart for commissioning services and protocols Commissioning IGP（Static Route, OSPF, ISIS） Commissioning BGP （IBGP, EBGP） Commissioning MPLS LDP, MPLS TE Commissioning VPN （L3VPN, L2VPN） Commissioning BFD

5.1 Commissioning Static Routes Users can choose to configure a routing protocol based on the actual network planning. This section describes how to commission static routes. 5.2 Commissioning OSPF Routes Users can choose to configure a routing protocol based on the actual network planning. This section describes how to commission OSPF routes. Issue 02 (2011-09-10)


46



5.3 Commissioning IS-IS Routes Users can choose to configure a routing protocol based on the actual network planning. This section describes how to commission IS-IS routes. 5.4 Commissioning IBGP Routes Users can choose to configure the BGP routing protocol based on the actual network planning. This section describes how to commission IBGP routes. 5.5 Commissioning EBGP Routes Users can choose to configure the BGP routing protocol based on the actual network planning. This section describes how to commission EBGP routes. 5.6 Commissioning MPLS LDP Users can choose to configure a type of MPLS tunnel based on the actual network planning. This section describes how to commission MPLS LDP. 5.7 Commissioning MPLS TE Users can choose to configure a type of MPLS tunnel based on the actual network planning. This section describes how to commission MPLS TE. 5.8 Commissioning BGP/MPLS IP VPN This section describes how to commission BGP/MPLS IP VPN. 5.9 Commissioning VPWS MPLS L2VPN contains VPWS and VPLS technologies. This section describes how to commission VPWS. 5.10 Commissioning VPLS MPLS L2VPN contains VPWS and VPLS technologies. This section describes how to commission VPLS. 5.11 Commissioning BFD BFD sessions can quickly detect link faults on a network. This section describes how to commission BFD.

Issue 02 (2011-09-10)


47



5.1 Commissioning Static Routes Users can choose to configure a routing protocol based on the actual network planning. This section describes how to commission static routes.

Prerequisite The following configurations are complete and the device is running normally: l


l


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

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB

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/0/0 127.0.0.0/8 127.0.0.1/32 127.255.255.255/32 192.167.1.0/24

Direct Direct Direct Static

0 0 0 60

0 0 0 0

D D D D

127.0.0.1 127.0.0.1 127.0.0.1 192.168.1.2

InLoopBack0 InLoopBack0 InLoopBack0 GigabitEthernet1/0/0

The command output in bold shows the static route between the commissioning device and the network connected to Router 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 ------------------------------------------------------------------------------

Issue 02 (2011-09-10)


48



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

Configured Routes : 1 NextHop 192.168.1.2

Interface

The command output in bold shows the information about the activated static routes. Then check the number of activated static routes, destination network addresses, preferences, costs, nexthop 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.10 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 Router 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.


5.2 Commissioning OSPF Routes Users can choose to configure a routing protocol based on the actual network planning. This section describes how to commission OSPF routes. Issue 02 (2011-09-10)


49





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 toRouter B. Figure 5-3 Typical networking for commissioning OSPF routes 1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB

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(GigabitEthernet1/0/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 field in bold in the command output shows 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, it indicates that 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 Routing Tables Routing for Network Destination Cost 192.168.1.0/24 1 2.2.2.2/32 1

Issue 02 (2011-09-10)

Type transit Stub

NextHop 192.168.1.1 192.168.1.2

AdvRouter 1.1.1.1 2.2.2.2


Area 0.0.0.0 0.0.0.0

50



192.167.1.0/24 2 Stub Total Nets: 3 Intra Area: 3 Inter Area: 0

192.168.1.2 ASE: 0

2.2.2.2

0.0.0.0

NSSA: 0

In the command output, check the destination network addresses, route costs, destination network types, next-hop addresses, routers advertising the routes, AS numbers, and total number of networks of each type. The OSPF routes in the preceding command output are intra-area routes. Inter-area OSPF routes: 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 Total Nets: 5 Intra Area: 2

Type transit Stub Inter-area

Cost 3 3

Inter Area: 1

NextHop 192.168.1.1 192.168.1.2 192.168.1.2

Type Type1 Type1 ASE: 2

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

NSSA: 0

If the commissioning device has learned routes from other areas using OSPF, the routing table will contain them. The field in bold in the command output shows that there are two intra-area routes, one inter-area routes, 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 field in bold in the command output shows 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 0.0.0.255 network 1.1.1.1 0.0.0.0 #

The field in bold in the command output shows 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. Issue 02 (2011-09-10)


51



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



ms ms ms ms ms


Issue 02 (2011-09-10)


52



The preceding command output shows that the commissioning device has a reachable OSPF route to the network connected to Router 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, it indicates that the interface status has changed. In this case, run the display interface [ interface-type [ interface-number ] ] command to check the interface status, and then rectify the interface fault. – If the NeighborDownPrimeReason field displays OSPF Process Reset, it indicates that 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, it indicates that 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. l In other cases, go to Step 9. 2.

Check that the link between the two ends works normally. Check that the link between the two ends is working normally, including the transmission devices. If the link works properly, go to Step 3.

3.

Check that the CPU usage is within the normal range. Check whether or not the CPU usage on the MPU or LPU of the faulty device is too high. If the CPU usage is too high, OSPF fails to receive and send protocol packets, causing the

Issue 02 (2011-09-10)


53



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) State Cost

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 Retransmit Count: 0 Neighbor cumulative data. (Total) ------------------------------------------------------Down: 0 Init: 0 Attempt: 0 2-Way: 0 Exstart: 0 Exchange: 0 Loading: 0 Full: 1 Retransmit Count: 0

l If the OSPF status of the interface is normal (for example, DR, BDR, DR Other, or P2P), go to Step 5. 5.

Issue 02 (2011-09-10)

Check that the IP addresses of the two ends are on the same network segment.


54



l If the IP addresses of the two ends are on different network segments, modify the IP address of one end. l If the IP addresses of the two ends are on the same network segment, go to Step 6. 6.

Check that MTUs of the interfaces on both ends are consistent. If ospf mtu-enable is enabled on the interfaces, the interface MTUs must be consistent. Otherwise, OSPF neighbors cannot negotiate with each other successfully. l If MTUs of the interfaces on both ends are inconsistent, run the mtu mtu command in the interface view to change MTUs of the interfaces to be consistent on both ends. l If the MTUs of the interfaces on both ends are consistent, go to Step 7.

7.

Check that there is at least one interface whose priority is not 0. On the broadcast and NBMA networks, there should be at least one interface whose priority is not 0, which ensures that a DR is elected correctly. Otherwise, the state of the OSPF neighbor relationship can only reach 2-Way. Run the display ospf interface command to view the interface priority. 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. (1) 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. (2) 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 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

Pri

DR

1

192.168.1.1

(3) Check whether other OSPF configurations on both ends are consistent. Run the display ospf error command every 10s for 5 minutes. display ospf error OSPF Process 1 with Router ID 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

Issue 02 (2011-09-10)

1.1.1.1 0 0 0

: Bad packet : Bad checksum : Drop on unnumbered

0 0 0 0

: : : :

0 0

: Hello timer mismatch : Extern option mismatch


Bad authentication type Packet too small Transmit error Unknown neighbor

55

HUAWEI NetEngine80E/40E Router Commissioning Guide 0 0

5 Commissioning Services and Protocols : Router id confusion : NBMA neighbor unknown

0 0

: Virtual neighbor unknown : Invalid Source Address

l Check the Bad authentication type field. If the value of this field continually increases, it indicates that the OSPF authentication types of the two ends that establish the neighbor relationship are different. In this case, you need to set the same authentication type for both ends. l Check the Hello timer mismatch field. If the value of this field continually increases, it indicates that the value 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, it indicates that the value of 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, it indicates that the area types of the two ends that establish the neighbor relationship are different (the area type of one device is common area, and that of the other device is stub area or NSSA). In this case, you need to set the same area type for both ends. If the fault persists, proceed to Step 9. 9.

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 devices

5.3 Commissioning IS-IS Routes Users can choose to configure a routing protocol based on the actual network planning. This section describes how to commission IS-IS routes.



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 Router B. Figure 5-4 Typical networking for commissioning IS-IS routes 1.1.1.1/32

Console PC

Issue 02 (2011-09-10)

2.2.2.2/32

192.168.1.1 / 24 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB


56



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.0000.0001 GE1/0/0 0000.0000.0001.01 Up 24s L2 64 Total Peer(s): 1

The field in bold in the command output shows 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(1) ----------------------------------Interface Id IPV4.State IPV6.State Loop0 001 Up Down GE1/0/0 001 Up Down

MTU Type DIS 1500 L1/L2 -1497 L1/L2 No/No

The field in bold in the command output shows IS-IS interface information. Check that OSPFenabled interfaces are correctly configured, the number of OSPF-enabled interfaces are 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 GE1/0/0 192.168.1.2 A/-/-/192.168.1.0/24 10 NULL GE1/0/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. Step 4 Run the display current-configuration command on the commissioning device to check the configurations that have taken effect. display current-configuration # isis 1 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

Issue 02 (2011-09-10)


57



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



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 Router B. ----End

Troubleshooting If the IS-IS neighbor relationship cannot be established after IS-IS is configured, complete the following: 1.

Check that IS-IS can receive and send Hello packets properly. Run the display isis statistics packet [ interface interface-type interface-number ] command to check that IS-IS can normally receive and send Hello packets. NOTE

The default interval at which IS-IS sends Hello packets is 10s. Therefore, run this command every 10s to check whether or not the packet statistics increase. On a broadcast interface, IS-IS Hello packets have IS-IS levels, and therefore you can view Hello packet statistics based on the levels of established neighbor relationships. On a P2P interface, IS-IS Hello packets have no IS-IS levels and are recorded as L2 IIH packets.

l If the number of received Hello packets does not increase for a certain period, check whether or not packet loss has occurred at the lower layer or at the link between the two ends. l If the number of received Hello packets increases gradually, perform the following operations based on interface types: – 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 Step 2. 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.

Issue 02 (2011-09-10)


58



l If the interface status is not Up, rectify the interface fault. For detailed troubleshooting procedures, see "Interface & Physical Connection Troubleshooting" and "Layer 2 Network Troubleshooting." l If the interface status is Up, go to Step 3. 3.

Check the status of IS-IS interfaces. Run the display isis interface command to check the status of the interfaces enabled with IS-IS. l If the interface status is Mtu:Dn/Lnk:Up/IP:Up, run the display 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 Step 4.

4.

Check that the IP addresses of the two ends are on the same network segment. l If the IP addresses of the two ends are on different network segments, modify the IP address of one end. l If the IP addresses of the two ends are on the same network segment, go to Step 5.

5.

Check that both ends are configured with different system IDs. Run the display current-configuration configuration isis command to check whether or not the system IDs of the two ends are the same. l If the system IDs of the two ends are the same, set different system IDs for each end. l If the system IDs of the two ends are different, go to Step 6.

6.

Check that the IS-IS levels of the two ends are consistent. Run the display current-configuration configuration isis | include is-level command to check the levels of the IS-IS processes on both ends. Then, run the display 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. 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 Step 7.

7.

Check that the area addresses of the two ends are the same. When the area addresses of the two ends are different, the alarm isisAreaMismatch is generated.

Issue 02 (2011-09-10)


59



NOTE

If the two ends establish a Level-1 neighbor relationship, ensure that they are both in the same area. An IS-IS process can be configured with a maximum of three area addresses. As long as one of the area addresses of the local IS-IS process is the same as one of the area addresses of the remote IS-IS process, the Level-1 neighbor relationship can be established. When an IS-IS Level-2 neighbor relationship is established between two ends, you do not need to determine whether or not the area addresses of the two ends are the same.

l If the area addresses of the two ends are different, run the network-entity command in the IS-IS view to set the same area address for both ends. l If the area addresses of the two ends are the same, go to Step 8. 8.

Check that the authentication configurations on the two ends are the same. If the authentication modes configured on the two ends are different, the alarm isisAuthenticationTypeFailure or isisAuthenticationFailure is generated. Run the display current-configuration interface interface-type interface-number | include isis authentication-mode command to check IS-IS authentication configurations on the interfaces of the two ends. l If the authentication modes configured on both are different, run the isis authenticationmode command in the IS-IS interface view on both ends to set the same authentication mode. l If the authentication modes configured on both ends are the same, go to Step 9.

9.

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 devices

5.4 Commissioning IBGP Routes Users can choose to configure the BGP routing protocol based on the actual network planning. This section describes how to commission IBGP routes.



l


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 Router 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 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB

AS100

Issue 02 (2011-09-10)


60



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 2.2.2.2 4

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 command output in bold shows 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 command output in bold shows the default route and specific routes received from AS 300, summarized routes received from AS 400, and that 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: 1 available, 1 best, 1 select BGP routing table entry information of 192.167.1.0/24: Imported route. From: 2.2.2.2 (2.2.2.2) Route Duration: 00h14m33s Direct Out-interface: GigabitEthernet1/0/0 Original nexthop: 2.2.2.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 Not advertised to any peer yet

The command output in bold shows detailed information about the specified IBGP routes. Check that the local router IDs, AS numbers, sources of IBGP routes, outbound interfaces, Issue 02 (2011-09-10)


61



and next-hop addresses are correct. The IBGP routes in the command output have community attributes, which prevents Router A from advertising the routes received from Router 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

MED 0

LocPrf 100

PrefVal Community 0 no-export

l Commissioning the RR of IBGP routes: Router B is the RR of cluster 1 and Router A is the client of Router 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: 1 available, 1 best, 1 select BGP routing table entry information of 192.167.1.0/24: From: 2.2.2.2 (2.2.2.2) Route Duration: 00h14m33s Direct Out-interface: GigabitEthernet1/0/0 Original nexthop: 2.2.2.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 Originator: 4.4.4.4 Cluster list: 0.0.0.1 Not advertised to any peer yet

The command output in bold shows that Router A has learned routes of the network segment 192.167.1.0 advertised by Router 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 GTSM and 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

Issue 02 (2011-09-10)


62



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 GTSM has been enabled, valid-ttl-hops: 1 Peer Preferred Value: 0 Routing policy configured: No routing policy is configured

The command output in bold shows that the GTSM function has been enabled, 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 Router 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 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. Since the source address is specified in this command, you can check whether or not routes between the two ends are accessible. By specifying the size of a Ping packet, you can also check whether or not long Ping packets can be normally transmitted over the link.

l If the ping fails, follow the procedure described in "The Ping Operation Fails" in the HUAWEI NetEngine80E/40E Router Troubleshooting to find whether or not the routing tables on each end have available routes to each other. 2. Issue 02 (2011-09-10)

Check that no ACL is configured to filter packets whose destination port is TCP port 179. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

63



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 If an ACL is configured to filter packets whose destination port is TCP port 179, delete the ACL configuration. l If no ACL is configured to filter packets whose destination port is TCP port 179, go to Step 3. 3.

Check that the peer router ID does not conflict with the local router ID. Check information about BGP peers to ensure that their router IDs do not conflict. For example, if the IPv4 unicast peer relationship fails to be established, you can run the display bgp peer command to check whether or not the peer router ID conflicts with the local router ID. Use the following command output as an example: display BGP local router Local AS number Total number of Peer PrefRcv 8.9.0.8 10000 9.10.0.10 9999

bgp peer ID : 223.5.0.109 : 41976 peers : 12

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.

l If the peer router ID conflicts with the local router ID, run the router id command in the BGP view to modify the router IDs to agree. Generally, a loopback interface address is used as the local router ID. l If the peer router ID does not conflict with the local router ID, go to Step 4. 4.

Check that the peer AS number is configured correctly. Run the display bgp peer command on each end to check that the displayed peer AS number is the same as that of the remote end. 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


NOTE


l If the peer AS number is configured incorrectly, change it to be the same as that of the remote end. Issue 02 (2011-09-10)


64



l If the peer AS number is configured correctly, go to Step 5. 5.

Check whether or not BGP configurations affect the establishment of the BGP peer relationship. Run the display current-configuration configuration bgp command to check BGP configurations. Table 5-1 Checklist for BGP configurations 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 valid-ttl-hops hops

If the peer valid-ttl-hops hops command is configured, check that the hops value is correct. The valid TTL range of the detected packet is [255 - hops + 1, 255]. hops specifies the hop count between BGP peers, and the hop count between two directly connected devices is 1. NOTE The peer valid-ttl-hops command must be configured on both ends before setting up the BGP session.

Issue 02 (2011-09-10)

peer route-limit limit

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

peer ignore

If the peer ignore command is configured on the peer, it indicates that the peer is not required to establish the BGP peer relationship with the local end temporarily. To establish the BGP peer relationship between the remote peer and local peer, run the undo peer ignore command on the peer.

Address family capability

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


65


6.



5.5 Commissioning EBGP Routes Users can choose to configure the BGP routing protocol based on the actual network planning. This section describes how to commission EBGP routes.



l


Context On the network shown in Figure 5-6, EBGP is configured on the network to ensure successful communication between the commissioning device and the network connected to Router B. Figure 5-6 Typical networking for commissioning EBGP routes

1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB

AS100

AS200

Procedure Step 1 Run the display bgp peer command to view EBGP peer information. BGP local router ID : 1.1.1.1 Local AS number : 100 Total number of peers : 1 Peer V AS MsgRcvd MsgSent 2.2.2.2 4 200 9 19

Peers in established state : 1 OutQ Up/Down State 0 03:07:01 Established

PrefRcv 1

The command output in bold shows EBGP peer information. Check that the EBGP peer address and AS number are correct. Normally, the EBGP peer relationship should be in the Established state. Issue 02 (2011-09-10)


66



Step 2 Run the display bgp routing-table command on the commissioning device to view EBGP routing information. l View all EBGP 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: 4 Network NextHop Ogn *> 2.2.2.2/32 0.0.0.0 *> 192.168.1.0/24 0.0.0.0 * i 2.2.2.2 *> 192.168.1.1/32 0.0.0.0 *> 192.167.1.0/24 0.0.0.0 * 2.2.2.2 *> 1.1.1.1/32 0.0.0.0 *> 127.0.0.0 0.0.0.0 *> 127.0.0.1/32 0.0.0.0 *> 0.0.0.0 200.1.2.1 *> 9.1.1.0 200.1.2.1 *> 10.0.0.0 200.1.2.1

MED 1 0 0 0 0 0 0 0 0 0 0

LocPrf

100

100 100 100

PrefVal Path/ 0 0 0 0 0 0 0 0 0 0 0 0

? ? i ? ? 200i ? ? ? 300? 300? 400?

Check that the network addresses, next-hop addresses, metrics, and local preferences of BGP routes are correct. The command output in bold shows the specific routes received from AS 200, default route and specific routes received from AS 300, summarized routes received from AS 400, and that 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 EBGP 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: 2.2.2.2 (2.2.2.2) Route Duration: 00h14m33s Direct Out-interface: GigabitEthernet1/0/0 Original nexthop: 2.2.2.2 Qos information : 0x0 Community:no-export AS-path 200, origin igp, MED 0, pref-val 0, valid, external, best, select, pre 255 Not advertised to any peer yet

The command output in bold shows detailed information about the specified IBGP routes. Check that the local router IDs, AS numbers, sources of EBGP routes, outbound interfaces, and next-hop addresses are correct. The EBGP routes in the command output have community attributes, which prevents Router A from advertising the routes received from Router 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 *> 192.167.1.0 2.2.2.2

Issue 02 (2011-09-10)

MED 0


LocPrf 100

PrefVal Community 0 no-export

67



Step 3 Run the display bgp peer ipv4-address verbose command to view the configurations of GTSM and GR functions for EBGP. display bgp peer 2.2.2.2 verbose BGP Peer is 2.2.2.2, remote AS 200 Type: EBGP link BGP version 4, Remote router ID 2.2.2.2 Update-group ID : 2 BGP current state: Established, Up for 00h49m35s BGP current event: RecvKeepalive BGP last state: OpenConfirm BGP Peer Up count: 1 Received total routes: 1 Received active routes total: 1 Advertised total routes: 3 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 Multi-hop ebgp has been enabled GTSM has been enabled, valid-ttl-hops: 1 Peer Preferred Value: 0 Routing policy configured: No routing policy is configured

The command output in bold shows that the GTSM function has been enabled, the number of valid hops is 1, the BGP peer relationship is in the Established state, and the GR function is enabled for EBGP. Step 4 Run the display bgp routing-table dampening parameter command and the display bgp routing-table dampened command to view the configured EBGP route dampening parameters, and dampened EBGP routes respectively. display bgp routing-table dampening parameter Maximum Suppress Time(in second) : 3973 Ceiling Value : 16000 Reuse Value : 750 HalfLife Time(in second) : 900 Suppress-Limit : 2000 Route-policy : dampen-policy display bgp routing-table dampened Total Number of Routes: 1 BGP Local router ID is 1.1.1.1 Status codes: * - valid, > - best, d - damped,

Issue 02 (2011-09-10)


68



Network d 192.168.1.0

h - history, i - internal, s - suppressed, S - Stale Origin codes: i - IGP, e - EGP, ? - incomplete From Reuse Path 2.2.2.2 00:09:33 200 i

Step 5 Run the ping command on the commissioning device to test the availability of EBGP 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 Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=254 Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=254 Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=254 Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=254

time=70 time=65 time=64 time=90 time=25

ms ms ms ms ms


2.2.2.2 is the loopback address of Router B. ----End

Troubleshooting If the BGP peer relationship cannot be established on a BGP-deployed network, complete the following: 1.

Run the ping command to check that BGP peers can ping each other successfully. l If they can ping each other successfully, it indicates that there are available routes between the BGP peers and that link transmission is normal. Proceed to Step 2. NOTE

Run the ping -a source-ip-address -s packetsize host command to detect the connectivity of each end. Because the source address is specified in this command, you can check whether or not routes between the two ends are accessible. By specifying the size of a Ping packet, you can also check whether or not long Ping packets can be normally transmitted over the link.

l If the ping fails, follow the procedure described in "The Ping Operation Fails" in the HUAWEI NetEngine80E/40E Router Troubleshooting to find whether or not the routing tables of each end have available routes to each other. 2.

Check that no ACL is configured to filter packets whose destination port is TCP port 179. Run the display acl all command on both ends to check whether or not an ACL is configured to filter packets whose destination port is TCP port 179. display acl all Total nonempty ACL number is 1 Advanced ACL 3001, 2 rules Acl's step is 5 rule 5 deny tcp source-port eq bgp rule 10 deny tcp destination-port eq bgp

l If an ACL is configured to filter packets whose destination port is TCP port 179, delete the ACL configuration. l If no ACL is configured to filter packets whose destination port is TCP port 179, go to Step 3. 3.

Check that the peer router ID does not conflict with the local router ID. Check information about BGP peers to ensure that their router IDs do not conflict. For example, if the IPv4 unicast peer relationship fails to be established, you can run the display

Issue 02 (2011-09-10)


69



bgp peer command to check whether or not the peer router ID conflicts with the local router ID. Take the following command output as an example: display BGP local router Local AS number Total number of Peer PrefRcv 8.9.0.8 10000 9.10.0.10 9999

bgp peer ID : 223.5.0.109 : 41976 peers : 12


V

AS

MsgRcvd

4

100

1601

4

200

1565

MsgSent 1443 1799

OutQ

Up/Down

State


NOTE


l If the peer router ID conflicts with the local router ID, run the router id command in the BGP view to modify the router IDs to agree. Generally, a loopback interface address is used as the local router ID. l If the peer router ID does not conflict with the local router ID, go to Step 4. 4.

Check that the peer AS number is configured correctly. Run the display bgp peer command on each end to check that the displayed peer AS number is the same as that of the remote end. 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


NOTE


l If the peer AS number is configured incorrectly, change it to be the same as that of the remote end. l If the peer AS number is configured correctly, go to Step 5. 5.

Check whether or not BGP configurations affect the establishment of the BGP peer relationship. Run the display current-configuration configuration bgp command to check BGP configurations. Table 5-2 Checklist for BGP configurations

Issue 02 (2011-09-10)

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.


70



Item

Description

peer ebgp-max-hop hop-count

If two directly connected devices use loopback interfaces to establish the EBGP peer relationship or two indirectly connected devices establish the EBGP peer relationship, you need to run the peer ebgp-max-hop command to specify the maximum hop count between them. l If two directly connected devices use loopback interfaces to establish the EBGP peer relationship, the hop count can be any number greater than 1. l If two indirectly connected devices establish the EBGP peer relationship, you need to specify the actual hop count.

peer valid-ttl-hops hops

If the peer valid-ttl-hops hops command is configured, check that the hops value is correct. The valid TTL range of the detected packet is [255 - hops + 1, 255]. hops specifies the hop count between BGP peers, and the hop count between two directly connected devices is 1. NOTE The peer valid-ttl-hops command must be configured on both ends before setting up the BGP session.

Issue 02 (2011-09-10)

peer route-limit limit

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

peer ignore

If the peer ignore command is configured on the peer, it indicates that the peer is not required to establish the BGP peer relationship with the local end temporarily. To establish the BGP peer relationship between the remote peer and local peer, you can run the undo peer ignore command on the peer.

Address family capability

Check that the address family capabilities of on both 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.


71


6.



5.6 Commissioning MPLS LDP Users can choose to configure a type of MPLS tunnel based on the actual network planning. This section describes how to commission MPLS LDP.



l


Context On the network shown in Figure 5-7, MPLS LDP is configured on the network. Figure 5-7 Typical networking for commissioning MPLS LDP 1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB

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 GigabitEthernet1/0/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

Issue 02 (2011-09-10)


72



-------------------------------------------------------------------------2.2.2.2:0 Operational DU Active 0000:00:22 12984/12991 -------------------------------------------------------------------------TOTAL: 1 Session(s) Found.

The Status field in the preceding command output is commonly displayed as Operational, indicating that an LDP session has been established. The LAM field is commonly displayed as DU, indicating that the label distribution mode is Downstream Unsolicited. The SsnRole field can be displayed as Passive, indicating the responder of an LDP session, or as Active, indicating the initiator of an LDP session. Step 3 Run the display mpls ldp interface command on the commissioning device to view information about the interfaces enabled with MPLS LDP. 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 HelloSent/Rcv ------------------------------------------------------------------------------GE1/0/0 Active DU 1.1.1.1 56259/0 -------------------------------------------------------------------------------

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 GE1/0/0 3.3.3.3/32 1657/2075 2.2.2.2 192.168.1.2 GE1/0/0 2.2.2.2/32 NULL/3 192.168.1.2 GE1/0/0 2.2.2.2/32 1656/3 2.2.2.2 192.168.1.2 GE1/0/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 -/GE1/0/0 2.2.2.2/32 1656/3 -/GE1/0/0 3.3.3.3/32 NULL/2075 -/GE1/0/0 3.3.3.3/32 1657/2075 -/GE1/0/0

Step 6 Run the display mpls lsp verbose command on the commissioning device to view detailed LSP information. display mpls lsp verbose ----------------------------------------------------------------------

Issue 02 (2011-09-10)


73



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

Issue 02 (2011-09-10)

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

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

2


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

3

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

: : : : : : : : : :

4

2.2.2.2/32 192.168.1.2 NULL 3 ---------GigabitEthernet1/0/0 72705 0x8000007 0x0 Ingress 0x0 PUSH -----944sec --------

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

3.3.3.3/32 192.168.1.2 NULL 2075 ---------GigabitEthernet1/0/0 72707 0x8000009


74



FrrToken LsrType Outgoing token Label Operation Mpls-Mtu TimeStamp Bfd-State BGPKey

: : : : : : : :

0x0 Ingress 0x0 PUSH 1500 944sec --------


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

5 3.3.3.3/32 192.168.1.2 1657 2075 ---------GigabitEthernet1/0/0 72708 0x800000a 0x0 Transit 0x0 SWAP 1500 944sec --------

The command output in bold shows 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 32 LSP PING FEC: IPV4 PREFIX 3.3.3.3/32 : 100 data bytes, press CTRL_C to break Reply from 3.3.3.3: bytes=100 Sequence=1 time = 26 ms 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 HUAWEI B are transmitted along an LSP. All the PEs related to services need to be checked. ----End

Troubleshooting If the established LDP session is in the Down state on an LDP-deployed network, complete the following: 1.

Check whether the interface on which the LDP session is established is shut down. Run the display this command in the interface view. If the command output contains shutdown, the interface is shut down. l If the interface is shut down, run the undo shutdown command in the interface view to start the interface.

Issue 02 (2011-09-10)


75



l If the interface is not shut down, go to Step 2. 2.

Check whether commands for deleting MPLS configurations have been executed. Run the display current-configuration command to check whether commands for deleting MPLS configurations have been executed. l If the command output does not contain mpls, MPLS is disabled. l If the command output does not contain mpls ldp, MPLS LDP is disabled. l If the command output does not contain mpls ldp remote peer, the session established with the remote LDP peer has been deleted. l If any command for deleting MPLS configurations has been run, run corresponding commands to restore the deleted configurations. l If no command for deleting MPLS configurations has been run but the fault persists, go to Step 3.

3.

Check that routes are available. Run the display ip routing-table command and check the Destination/Mask field in the command output to find out whether there is a route to the peer device. If there is no route to the peer device, the TCP connection cannot be established. l If the route to the peer device is unreachable, follow the procedure described in "The Ping Operation Fails" in the HUAWEI NetEngine80E/40E Router Troubleshooting to rectify the IGP route fault. l If the route to the peer device is reachable, go to Step 4.

4.

Check whether an LDP Hello-hold timer expires. Run the display mpls ldp interface command to check that both ends of the LDP session can send Hello messages. It is recommended that the display mpls ldp interface command be run every 3 seconds. If the statistics on sent or received messages remain unchanged, it indicates that the transmission of Hello messages is abnormal, and the Hello-hold timer expires. l If the Hello-hold timer expires, see the troubleshooting of high CPU usage. l If the Hello-hold timer does not expire, go to Step 5.

5.

Check whether the LDP Keepalive-hold timer expires. Run the display mpls ldp session command to check that both ends of the LDP session can send Keepalive messages. It is recommended that the display mpls ldp session command be run every 5 seconds. If the statistics on sent or received messages remain unchanged, it indicates that the transmission of Keepalive messages is abnormal, and the Keepalive-hold timer expires. l If the Keepalive-hold timer expires, follow the procedure described in "The Ping Operation Fails" in the HUAWEI NetEngine80E/40E Router Troubleshooting to rectify the fault in message forwarding. l If the Keepalive-hold timer does not expire, go to Step 6.

6.


5.7 Commissioning MPLS TE Users can choose to configure a type of MPLS tunnel based on the actual network planning. This section describes how to commission MPLS TE. Issue 02 (2011-09-10)


76





l


Context On the network shown in Figure 5-8, MPLS TE is configured on the network. Figure 5-8 Typical networking for configuring MPLS TE 1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB

Procedure Step 1 Run the display interface tunnel command on the commissioning device to view basic information about tunnel interfaces. display interface tunnel Tunnel1/0/0 current state : UP Line protocol current state : UP Last line protocol up time : 2010-02-05 15:12:16 Description: HUAWEI, Quidway Series, Tunnel1/0/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 1 Tunnel protocol/transport MPLS/MPLS, ILM is available, primary tunnel id is 0x6000001, secondary tunnel id is 0x0 Current system time: 2010-02-05 15:16:34 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 command output in bold shows 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 ================================================================ Tunnel1/0/0 ================================================================ Tunnel State Desc : Up

Issue 02 (2011-09-10)


77



Active LSP Session ID Ingress LSR ID Admin State Primary LSP State Main LSP State

: : : : : :

Primary LSP 100 1.1.1.1 UP UP READY

Egress LSR ID: Oper State :

3.3.3.3 UP

LSP ID

1

:

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 Maximum Nodes Supported: Maximum Links Supported: Maximum SRLGs supported: Id 1 2 3

Router-Id 1.1.1.1 2.2.2.2 3.3.3.3

cspf tedb all 2000 Current Total Node Number: 3 8000 Current Total Link Number: 4 10000 Current Total SRLG Number: 0

IGP ISIS ISIS ISIS

Process-Id 1 1 1

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: GigabitEthernet1/0/0 Interface Address: 192.168.1.1 Interface state: UP Interface Index: 0x6 Total-BW: 100000 Used-BW: 20000 Hello configured: NO Num of Neighbors: 1 SRefresh feature: DISABLE SRefresh Interval: 30 sec Mpls Mtu: 1500 Retransmit Interval: 5000 msec Increment Value: 1 Authentication: DISABLE Bfd Enabled: DISABLE Bfd Min-Tx: 10 Bfd Min-Rx: 10 Bfd Detect-Multi: 3

The command output in bold shows 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: 0x8277E43C PSB Count: 1 Hello Type Sent: NONE SRefresh Enable: NO Last valid seq # rcvd: NULL Interface GigabitEthernet1/0/0 Neighbor Addr: 192.168.1.2 SrcInstance: 0x8277E43C PSB Count: 0 Hello Type Sent: NONE SRefresh Enable: NO Last valid seq # rcvd: NULL

NbrSrcInstance: 0x0 RSB Count: 0

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 tunnel 1/0/0

Issue 02 (2011-09-10)


78



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 Tunnel1/0/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 Tunnel1/0/0 ping statistics --5 packet(s) transmitted 5 packet(s) received 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. l If the commit command has not been executed, run it in the tunnel view. l If the commit command has been executed in the tunnel view, go to Step 2.

2.

Check that CSPF has been successfully calculating paths. Run the display mpls te cspf destination ip-address explicit-path path-name command on the TE tunnel ingress. If command output is displayed, CSPF has been successfully calculating paths; if no command output is displayed, CSPF failed to calculate a path. l If CSPF failed to calculate a path, check that routes to the destination of the TE tunnel exist. – If no route exists, follow the procedure described in "The Ping Operation Fails" in the HUAWEI NetEngine80E/40E Router Troubleshooting to rectify the route fault. – If reachable routes exist and they satisfy the requirements to establish a TE tunnel, rectify the fault by referring to the section "CSPF Calculation Fails." l If CSPF has been successfully calculating paths but the fault persists, go to Step 3.

3.

Check that RSVP is enabled on every device along the TE tunnel. The command output of display mpls te cspf destination ip-address explicit-path 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. l If an interface is not enabled with RSVP, enable RSVP on the interface. l If all interfaces are enabled with RSVP but the fault persists, go to Step 4.

4.

Check that devices along the TE tunnel have been successfully exchanging RSVP Path and Resv messages. Run the display mpls te tunnel-interface command on the TE tunnel ingress and check fields Ingress LSR ID, LSP ID, and Session ID in the command output. In Step 3, LSR A, LSR B, and LSR C represent the nodes along the TE tunnel. Complete the following to check that the RSVP Path message and RSVP Resv message are correctly transmitted:

Issue 02 (2011-09-10)


79



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. – If the command output is empty on a node, it can be concluded that the node fails to receive RSVP Path messages from the upstream node. l Check that RSVP Resv messages are correctly transmitted in the sending direction (LSR C -> LSR B -> LSR A). Run the display mpls rsvp-te rsb-content command on every node the RSVP Resv message travels through. – If the command output is not empty on any node, it can be concluded that RSVP Resv messages are correctly transmitted. – If the command output is empty on a node, it can be concluded that the node fails to receive RSVP Resv messages from the upstream node. l If messages fail to be properly exchanged, follow the procedure described in "The Ping Operation Fails" in the HUAWEI NetEngine80E/40E Router Troubleshooting to rectify the message forwarding fault. l If messages are properly exchanged but the fault persists, go to Step 5. 5.


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



l


Context On the network shown in Figure 5-9, BGP/MPLS IP VPN is configured on the network. Figure 5-9 Typical networking for commissioning BGP/MPLS IP VPN 1.1.1.1/32

2.2.2.2/32

192.168.1.1/24 GE1/0/0

100.1.1.1/24 100.1.2.1/24 GE1/0/0 GE2/0/0 GE2/0/0 GE1/0/0 192.168.1.2/24 100.1.2.2/24 100.1.1.2/24 GE2/0/0 CE1 PE:RouterA PE:RouterB CE2

Issue 02 (2011-09-10)


80



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 VPN-Instance Name and ID : vpna, 1 Interfaces : GigabitEthernet1/0/0 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 Established 0

0

03:12:16

Established

9

Check that the number of BGP peers and the number of configured VPN instances are correct. The command output in bold shows 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 receivedroutes 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/

Issue 02 (2011-09-10)


81

HUAWEI NetEngine80E/40E Router Commissioning Guide Ogn *> *> * *>


1.1.1.1/32 2.2.2.2/32 100.1.1.0/24 192.168.1.0

100.1.1.1 100.1.1.1 100.1.1.1 100.1.1.1

0 0 0 0

0 0 0 0

65410? 65410? 65410? 65410?

Check that the sent and received BGP routes are correct. First check whether the routes sent by the PE are correct, meaning whether some necessary routes are not sent but some unnecessary routes are sent. Then do the same for the routes received from the peer PE. Step 4 Run the display ip routing-table vpn-instance command on the commissioning device to view the routing table of the VPN instance. 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 GigabitEthernet1/0/0 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 0 RD 2.2.2.2 GigabitEthernet1/0/0 255.255.255.255/32 Direct 0 0 D 127.0.0.1 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 command output in bold shows 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-instance 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.

Issue 02 (2011-09-10)


82



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. 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 Relay IP Nexthop: 20.1.1.2 Relay IP Out-Interface: GigabitEthernet1/0/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 #

Issue 02 (2011-09-10)


83



bgp 100 peer 1.1.1.1 as-number 200 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 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 HUAWEI NetEngine80E/40E Router Configuration Guide - IP Routing. l If inbound and outbound policies are not configured on the two ends, go to Step 3. 3.

Check that routes can be iterated to a tunnel. Run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command on the remote PE to check whether the target route can be iterated to a tunnel. Assume that the target route is a route to 50.1.1.2/32. If the Relay Tunnel Out-Interface field and Relay token field in the command output are not empty, this route can be iterated to a tunnel. 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: GigabitEthernet1/0/0 Relay Tunnel Out-Interface: GigabitEthernet1/0/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 (2011-09-10)


84



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: GigabitEthernet1/0/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, active, pre 255 Not advertised to any peer yet

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 details, see the section "MPLS" in HUAWEI NetEngine80E/40E Router Troubleshooting. l If the target route can be iterated to a tunnel, go to Step 4. 4.

Check whether routes fail to be added to the VPN routing table because the configured import RT and export RT do not match. Run the display current-configuration configuration vpn-instance command on the local PE and remote PE to check if routes fail to be added to the VPN routing table of the remote PE after being sent to the remote PE because the export RT of the local VPN instance does not match the import RT of the remote VPN instance. export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT. display current-configuration configuration vpn-instance # ip vpn-instance vpna ipv4-family route-distinguisher 1:1 vpn-target 111:1 export-extcommunity vpn-target 111:1 import-extcommunity apply-label per-instance vpn-target 1:1 export-extcommunity vpn-target 1:1 import-extcommunity ip vpn-instance vpnb ipv4-family route-distinguisher 1:2 vpn-target 1:1 export-extcommunity vpn-target 1:1 import-extcommunity # return

l If the export RT of the local VPN instance does not match the import RT of the remote VPN instance, configure matching VPN-targets in the VPN instance. l If the export RT of the local VPN instance matches the import RT of the remote VPN instance, go to Step 5. 5.

Check that the number of labels does not exceed the limit. Check that MPLS is enabled on the local PE. Then, run the display bgp vpnv4 all 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, it indicates that 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 (2011-09-10)


85



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: NULL0 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, select, 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: NULL0 Original nexthop: 100.1.1.1 Qos information : 0x0 AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre 60 Not advertised to any peer yet

l If labels are insufficient, run the apply-label per-instance command in the VPN instance view to configure the device to assign a label to each instance to save labels. You can also configure route summarization to reduce the number of routes. l If labels are sufficient, go to Step 6. 6.

Check that the number of routes does not exceed the limit. Run the display current-configuration configuration bgp | include peer 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 is interrupted, the target route is dropped because the route limit has been exceeded, and the limit needs to be increased.

Issue 02 (2011-09-10)


86



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.


5.9 Commissioning VPWS MPLS L2VPN contains VPWS and VPLS technologies. This section describes how to commission VPWS.



l


Context On the network shown in Figure 5-10, VPWS is deployed on the network and Router A is a PE. Figure 5-10 Typical networking for commissioning VPWS 1.1.1.1/32 100.1.1.1/24 GE1/0/0.1 GE1/0/0.1 CE1

192.168.1.1/24 GE1/0/0

2.2.2.2/32 100.1.1.2/24 GE2/0/0.1 GE2/0/0.1

192.168.1.2/24 GE2/0/0 PE:RouterA PE:RouterB

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 1 up 0 down *client interface : GigabitEthernent1/0/0.1 Administrator PW : up session state : up AC status : up VC state : up Label state : 0 Token state : 0 VC ID : 101 VC type : VLAN destination : 2.2.2.2 local VC label : 21504 remote VC label control word : disable

Issue 02 (2011-09-10)


: 21504

87



forwarding entry : local group ID : manual fault : 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 :

existent 0 not set 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 (2011-09-10)

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.

88



Run the display mpls l2vc vc-id command to view VC information. display mpls l2vc 102 total LDP VC : 1 1 up 0 down *client interface : GigabitEthernet1/0/0.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 that the VC IDs of the two ends of the VC are the same. display mpls l2vc 102 total LDP VC : 1 1 up 0 down *client interface : GigabitEthernet1/0/0.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 tunnel policy name : -traffic behavior name: --

Issue 02 (2011-09-10)


: 146432

: 1500

89



PW template name primary or secondary create time up time last change time VC last up time VC total up time CKey

: : : : : : : :

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

16 NKey AdminPw interface AdminPw link state Diffserv Mode Service Class Color DomainId Domain Name

If the VC IDs of the two ends of the VC are different, change the VC ID of one end to be the same as that of the other. If the VC IDs of the two ends of the VC are the same but the fault persists, go to Step 3. NOTE

A VC can only be Up when the VC IDs of the two ends of the VC are the same.

3.

Check that the LDP session between the two ends is Up. display mpls l2vc 102 total LDP VC : 1 1 up 0 down *client interface : GigabitEthernet1/0/0.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 LDP session is Down, see the section "An LDP Session Is Down" in HUAWEI NetEngine80E/40E Router Troubleshooting to locate the fault and make the LDP session Up. If the LDP session is Up, go to Step 4. Issue 02 (2011-09-10)


90



NOTE

A VC can only be set up when the LDP session is Up.

4.

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

If the tunnel binding 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 is Down, see the section "An LSP Is Down" or "A TE Tunnel Is Down" in HUAWEI NetEngine80E/40E Router Troubleshooting to locate the fault and make the tunnel Up. If the tunnel is Up and the TE interfaces are correctly configured, go to Step 5. NOTE

A VC can only be Up when the tunnel that bears the VC is also Up.

5.

Check that the AC interfaces on the two ends are Up. Run the display mpls l2vcvc-id command on the two ends of the VC to check whether or not the AC status field is displayed as Up. l If the AC interfaces on the two ends are Down, see the section "Physical Interface Interconnection" in HUAWEI NetEngine80E/40E Router Troubleshooting to locate the fault and make the AC interfaces Up. l If the AC interfaces on the two ends are Up, go to Step 6. NOTE

A VC can only be Up when the AC interfaces on the two ends of the VC are also Up.

6.


5.10 Commissioning VPLS MPLS L2VPN contains VPWS and VPLS technologies. This section describes how to commission VPLS.

Issue 02 (2011-09-10)


91





l


Context On the network shown in Figure 5-11, VPLS is deployed on the network and Router A is a PE. Figure 5-11 Typical networking for commissioning VPLS 1.1.1.1/32 100.1.1.1/24 GE1/0/0.1 GE1/0/0.1 CE1

2.2.2.2/32

192.168.1.1/24 GE1/0/0

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

192.168.1.2/24 GE2/0/0 PE:RouterA PE:RouterB

CE2

Procedure Step 1 Run the display vsi command on the commissioning device to view VSI information. display vsi name v1 ***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 : Ignore AcState : Multicast Fast Swicth : Create Time : VSI State : VSI ID *Peer Router ID primary or secondary ignore-standby-state VC Label Peer Type Session Tunnel ID Broadcast Tunnel ID Broad BackupTunnel ID CKey NKey StpEnable PwIndex

Issue 02 (2011-09-10)

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

verbose v1 no disable 0 ldp static unqualify vlan 1500 uniform --255 disable enable 0 days, 0 hours, 50 minutes, 23 seconds up 10 2.2.2.2 primary no 23552 dynamic up 0x10002000 0x10002000 0x0 6 5 0 0


92



Interface Name State Last Up Time Total Up Time

: : : :

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

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

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

**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 GigabitEthernet2/0/0 Backup OutInterface Stp Enable Mac Flapping PW Last Up Time PW Total Up Time

: : : : :

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

Pay attention to the values of the fields displayed in bold. l PW Signaling is the signaling type of the PW, which can be LDP or BGP. l Member Discovery Style is the member discovery mode, which can be dynamic or 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

PeerIP 2.2.2.2

VcOrSiteId 1

PwState UP

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

Issue 02 (2011-09-10)


93



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 1500 up

l If the MTUs of the two ends are different, run the mtu mtu-value command in the VSI view to change the MTU of one end to be the same as that of the other. l If the MTUs of the two ends are consistent, go to Step 3. 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

Issue 02 (2011-09-10)

: : : : : : :

tt no disable 3 ldp static unqualify


94



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

: : : : : : : : : : :

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 up 0xc0060401 0xc0060401 6 5 0 0

: : : :



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

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

Issue 02 (2011-09-10)

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

tt no disable 3 ldp static unqualify vlan 1500 uniform --255

: : : :

101 2.2.2.2 187393 dynamic

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


95



Session Tunnel ID Broadcast Tunnel ID CKey NKey StpEnable PwIndex

: : : : : : :

up 0xc0060401 0xc0060401 6 5 0 0


: : : :


l If the LDP session between the two ends is Down, see the section "An LDP Session Is Down" in HUAWEI NetEngine80E/40E Router 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 "An LSP Is Down" or "A TE Tunnel Is Down" in HUAWEI NetEngine80E/40E Router 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. 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 Interface Interconnection" in HUAWEI NetEngine80E/40E Router 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.

Issue 02 (2011-09-10)


96


7.



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



l


Context On the network shown in Figure 5-12, BFD is configured on the network. Figure 5-12 Typical networking for commissioning BFD 1.1.1.1/32

Console PC

2.2.2.2/32

192.168.1.1 / 24 GE1/0/0 network GE2/0/0 GE3/0/0 192.168.1.2 / 24 192.167.1.10 / 24

RouterA

RouterB

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 GigabitEthernet1/0/0 discriminator local 1 discriminator remote 2 detect-multiplier 10 wtr 5 process-interface-status process-pst commit

If a single-hop BFD session is set up, process-pst must be configured. The command output in bold shows 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 -------------------------------------------------------------------------------Local Remote PeerIpAddr State Type InterfaceName -------------------------------------------------------------------------------1 2 192.168.0.2 Up S_IP_IF GigabitEthernet1/0/0

Issue 02 (2011-09-10)


97



-------------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0

The command output in bold shows BFD session information. Check that the number of BFD sessions is correct, the BFD session status is Up, and Local and Remote are correct. display bfd session all verbose -------------------------------------------------------------------------------Session MIndex : 16384 (One Hop) State : Up Name : atob -------------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer Ip Address : 192.168.1.2 NextHop Ip Address : 192.168.1.2 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 6 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 10 Detect Interval (ms) : 100 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc interface status : Enable Process PST : Disable WTR Interval (ms) : 5 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-5000000|RCV-0|IF-0|TOKEN-0 Session Description : ---------------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0

The command output in bold shows that after single-hop BFD is enabled, a single-hop BFD session is set up in the Up state. If multi-hop BFD is enabled, the command output will show that a multi-hop BFD session is set up in the Up state. If the BFD is associated with interface status successfully, the Proc interface status field will be displayed as Enable. ----End

Troubleshooting If the BFD session cannot become Up, complete the following: 1.

Run the display current-configuration configuration bfd-session command to check whether or not BFD session configurations have been committed. l If the commit field is displayed, BFD session configurations have been committed. Then go to Step 2. l If the commit field is not displayed, BFD session configurations have not been committed. In this case, run the commit command in the BFD session view, and then run the display bfd session all command to check that the BFD session is Up. – If the State field is displayed as Up, the BFD session has been created and no action is required. – If the State field is not Up, go to Step 2.

2.

Run the display bfd statistics session all slot slot-id command repeatedly to check statistics about BFD packets. l If the Received Packets value does not increase, go to Step 3.

Issue 02 (2011-09-10)


98



l If the Send Packets value does not increase, go to Step 4. l If both the Received Packets and Send Packets values increase properly, go to Step 7. l If none of the Received Packets, Send Packets, Received Bad Packets, and Send Bad Packets values increases, go to Step 5. l If the Down Count value increases, the BFD session flaps. In this case, go to Step 5. 3.

Run the display bfd statistics session all slot slot-id command repeatedly to check that the Received Bad Packets value increases properly. l If the Received Bad Packets value increases, the local end receives but discards the BFD packets sent from the remote end. In this case, go to Step 7. l If the Received Bad Packets value does not increase, the local end does not receive BFD packets. In this case, go to Step 5.

4.

Run the display bfd statistics session all slot slot-id command repeatedly to check that the Send Bad Packets value increases properly. l If the Send Bad Packets value increases, the BFD packets are sent but discarded. In this case, go to Step 7. l If the Send Bad Packets value does not increase, the local end does not send BFD packets to the remote end. In this case, go to Step 5.

5.

Run the display bfd statistics session all slot slot-id 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 HUAWEI NetEngine80E/40E Router Troubleshooting to rectify the packet forwarding fault. l If the ping succeeds, go to Step 6.

6.

Run the display current-configuration configuration bfd-session command to check the min-tx-interval and min-rx-interval values and determine whether or not the detection time value is larger than the delay value. l If the detection time value is smaller than the delay value, run the detect-multiplier, min-rx-interval, or min-tx-interval command to change the detection time value of the BFD session to be larger than the delay value. l If the detection time value of the BFD session is larger than the delay value, go to Step 7.

7.


Issue 02 (2011-09-10)


99


6 Commission Examples

6

Commission Examples

About This Chapter This section provides several typical commission examples. 6.1 Example for Commissioning an IP Bearer Network

Issue 02 (2011-09-10)


100



6.1 Example for Commissioning an IP Bearer Network Prerequisite The NE80E/40Es are installed, cabled, and loaded with configuration scripts.

Networking Figure 6-1 shows an IP core bearer network that provides multiple services such as 3G, Global System for Mobile Communication (GSM), Code Division Multiple Access (CDMA), and Internet services. This network consists of two layers, the core layer and the access layer. l

Core layer – This layer has two planes with each plane having five nodes that are fully meshed and located in five cities. The nodes on different planes are connected to each other through 10 Gbit/s Ethernet links, and backup paths are provided. – Intermediate System-to-Intermediate System (IS-IS) is used as an Interior Gateway Protocol (IGP) at the core layer, and Traffic Engineering (TE) tunnels are established between Ps on the same plane.

l

Access layer – Each NGW is dual-homed to two switches. Each switch is separately connected to a PE. The Virtual Router Redundancy Protocol (VRRP) runs between the PEs and switches, ensuring high availability of the link between the two switches. – EBGP peer relationships are established between the PEs and RRs at the core layer. – Remote LDP sessions are established between the PEs at different sites. – The PEs at the same site are connected to each other, switches, and core nodes by GE links. On each PE, the interface connected to a switch is called the user-side interface, and the interface connected to the backbone network is called the network-side interface. The user-side interface contains multiple sub-interfaces with each sub-interface being bound to a VPN instance and serving as the gateway for the corresponding CE. BFD runs on main interfaces.

Issue 02 (2011-09-10)


101



Figure 6-1 IP core network topology Site 14

Site 1

Site 13

RR

Site 2

Site 12

IGW P3 P1

Site 3

Site 11

Site 4

P5

P7

P2

P4

IGW

Site 5 P8

P6

Site 7

Site 6

Site 10

Site 8 RR Site 9

Whole topologies 10G GE

Site topologies Switch PE IP core nerword

NGW

Switch

PE

Procedure Step 1 1. Commission the hardware of each device. 1.

2.1 Logging In to the NE80E/40E by Using the Console Interface

2.

3.1 Checking the Software Version

3.

3.2 Checking the Health Status of the NE80E/40E

4.

3.3 Checking the Board Registration Status

5.

3.4 Checking the Fan Status

6.

3.5 Checking the Power Status

Issue 02 (2011-09-10)


102



7.

3.6 Checking System Time

8.

3.7 Checking the Interface Status

9.

3.8 Checking Alarm Information

10. 3.9 Checking the Voltage of Each Board 11. 3.10 Checking the Temperature of Each Board Step 2 Commission the link layer. NOTE

Commission the link layer after the hardware of each device is commissioned and the devices at the two ends of every link are normally started. The links between PEs and Ps need to be commissioned.

1.

4.1 Checking Ethernet Interfaces

2.

4.7 Checking the Optical Power of Interfaces

Step 3 Commission services and protocols. NOTE

After ensuring that all links work properly, commission routing protocols and services such as VPN services.

1.

5.3 Commissioning IS-IS Routes Commission IS-IS between IS-IS-capable Ps and PEs. IS-IS is enabled on the following interfaces: l All interfaces on Ps, including Loopback 0 interfaces l All interfaces on RRs, including Loopback 0 interfaces l Network-side interfaces on PEs, which connect the PEs to the MPLS backbone network l Loopback 0 interfaces on PEs l Interfaces connecting PEs and Ps

Issue 02 (2011-09-10)


103



Figure 6-2 IS-IS interfaces RR1 P3

P1

PE3

PE1

SW3

SW1 P5

P7

P2

SW2 PE2

P4

P6

P8

RR2

2.

SW4 PE4

ISIS interface

5.4 Commissioning IBGP Routes Figure 6-3 shows BGP connections at two sites as an example. At each of the two sites, two PEs are deployed to provide access services. In fact, there are 14 sites in the network, and each RR sets up MP-IBGP connections with 28 PEs.

Issue 02 (2011-09-10)


104



Figure 6-3 BGP connections RR1

RR2

P3 P1 PE3

PE1

P5

P7

PE2 P2

P4

PE4

P6 P8 MP-IBGP peer

3.

5.7 Commissioning MPLS TE Commission the following tunnels. l Tunnel paths Not more than four primary tunnels exist between each P and the other Ps. Figure 6-4 shows the primary tunnels between Ps on the same plane. All tunnel paths are defined based on the tunnel planning.

Issue 02 (2011-09-10)


105



Figure 6-4 Primary tunnels P3

P1

P7

P5

P2

P4

P8

P6

In the figure, P1, P2, P5, and P6 each serves as the ingress of three primary tunnels; P3, P4, P7, and P8 each serves as the ingress of two primary tunnels. In all, there are 20 primary tunnels. Based on the general tunnel design principle, all tunnels (including primary tunnels and backup tunnels) use strict explicit paths. Each primary tunnel has another tunnel as its backup. The primary and backup tunnels do not share the direct links between cities. Figure 6-5 shows the deployment of backup tunnels.

Issue 02 (2011-09-10)


106



Figure 6-5 Backup tunnels P3

P1

P7

P5

P2

P4

P8

P6

Primary tunnel Backup tunnel

Backup tunnels cannot use the direct links that have been used by the corresponding primary tunnels between cities. For example, the primary tunnel P1->P5 cannot have P1->P2->P6->P5 as its backup tunnel. Its backup tunnel can be P1->P2->P8->P6->P5 or P1->P2->P4->P6->P5. Table 6-1 Backup tunnel paths on the upper plane

Issue 02 (2011-09-10)

Primary Tunnel Path

Backup Tunnel Path

P1-P3

P1-P2-P6-P4-P3

P1-P5

P1-P2-P8-P6-P5

P1-P7

P1-P2-P6-P8-P7

P7-P1

P7-P8-P6-P2-P1

P7-P5

P7-P8-P2-P6-P5

P5-P7

P5-P6-P2-P8-P7

P5-P1

P5-P6-P8-P2-P1

P5-P3

P5-P6-P2-P4-P3

P3-P5

P3-P4-P2-P6-P5


107



Primary Tunnel Path

Backup Tunnel Path

P3-P1

P3-P4-P6-P2-P1

Table 6-2 Backup tunnel paths on the lower plane Primary Tunnel Path

Backup Tunnel Path

P2-P4

P2-P1-P5-P3-P4

P2-P6

P2-P1-P3-P5-P6

P2-P8

P2-P1-P5-P7-P8

P8-P2

P8-P7-P5-P1-P2

P8-P6

P8-P7-P1-P5-P6

P6-P8

P6-P5-P1-P7-P8

P6-P2

P6-P5-P3-P1-P2

P6-P4

P6-P5-P1-P3-P4

P4-P6

P4-P3-P1-P5-P6

P4-P2

P4-P3-P5-P1-P2

There is no direct link between P7 and P3. The path for the primary tunnel from P7 to P3 is shown in Figure 6-6. Hot backup and best-effort paths are configured to protect each link along the path. The design on the primary tunnel between P8 and P4 is similar to that on the primary tunnel between P7 and P3, and is not provided here.

Issue 02 (2011-09-10)


108



Figure 6-6 Primary tunnel path from P7 to P3 P3

P1

P7

P5

P2

P4

P8

4.

P6

5.8 Commissioning BGP/MPLS IP VPN Commission VPN instances on all PEs and user-side interfaces on PEs. Table 6-3 VPN parameters Parameter

Value

VPN name

l NGN_Media l NGN_Signal l NGN_Other

Issue 02 (2011-09-10)

VPN label allocation mode

Each VPN instance is assigned a label, and all the routes of a VPN instance use the same label.

VPN tunnel

LDP LSP


109



Parameter

Value

RD

The value is in the format of AAAAA:BBBBCCCDE. l AAAAA: indicates the BGP AS number (65000). l BBBB: indicates the VPN type. If the VPN is an enterprise VPN, the first two Bs identify the enterprise and the last two Bs identify the department. l CCC: indicates the site. l D: indicates the number of a PE on a plane at a site l E: indicates the site. The value 1 indicates plane A; the value 2 indicates plane B. See Table 4.

RT

Table 6-4 RDs and RTs VPN

Import RT

Export RT

Media stream

65000:0100

65000:0100

65000:0200 65000:0300 Signaling stream

65000:0100

65000:0200

65000:0200 65000:0300 Others

65000:0100

65000:0300

65000:0200 65000:0300 5.

5.11 Commissioning BFD BFD configurations consist of the following items: l BFD for TE hot-standby l BFD for VPN FRR l BFD for VRRP Commission BFD for TE hot-standby on all Ps. Establish BFD sessions between PEs at different sites on the same plane and commission BFD for VPN FRR.

Issue 02 (2011-09-10)


110



Commission BFD for VRRP on all PEs. ----End

Issue 02 (2011-09-10)


111


A List of Interface Attributes

A

List of Interface Attributes

This chapter presents the list of Interface Attributes. A.1 Interface Attributes of 100Base-FX A.2 Interface Attributes of 100/1000Base-CSFP A.3 Interface Attributes of 1000Base-X-SFP A.4 Interface Attributes of 10GBase LAN/WAN-XFP A.5 Interface Attributes of 10GBase LAN-SFP+ A.6 Interface Attributes of OC-3c/STM-1c cPOS-SFP A.7 Interface Attributes of OC-3c/STM-1c POS-SFP A.8 Interface Attributes of OC-12c/STM-4c POS-SFP A.9 Interface Attributes of OC-48c/STM-16c POS-SFP A.10 Interface Attributes of OC-192c/STM-64c POS-XFP A.11 Interface Attributes of OC-3c/STM-1c ATM-SFP A.12 Interface Attributes of OC-12c/STM-4c ATM-SFP

Issue 02 (2011-09-10)


112



A.1 Interface Attributes of 100Base-FX Table A-1 lists the interface attributes of 100Base-FX. Table A-1 Attributes of 100M SFP optical modules Attributes

Description

Transmission distance

2 km

15 km

40 km

80 km

Center wavelength

1310 nm

1310 nm

1310 nm

1550 nm

Minimum transmitting power

-19.0 dBm

-15.0 dBm

-5.0 dBm

-5.0 dBm

Maximum transmitting power

-14.0 dBm

-8.0 dBm

0 dBm

0 dBm

Receiving sensitivity

-30.0 dBm

-31.0 dBm

-37.0 dBm

-37.0 dBm

Overload power

-14.0 dBm

-8.0 dBm

-10.0 dBm

-10.0 dBm

Optical fiber type

Multi-mode

Single-mode

Single-mode

Single-mode

A.2 Interface Attributes of 100/1000Base-CSFP The interface attributes of 100/1000Base-CSFP see Table A-2. Table A-2 Interface attributes of the 100/1000Base-CSFP Attributes

Description

Connector type

LC/PC

Interface attributes

Compliant with the selected CSFP optical module.

Working mode

Full-duplex

Frame format

Ethernet_II, Ethernet_SAP, and Ethernet_SNAP

Network protocol

IP

Table A-3 Attributes of 100M CSFP optical modules

Issue 02 (2011-09-10)

Attributes

Description


10 km


113



Attributes

Description

Transmitting center wavelength

1550 nm

Receiving center wavelength

1310 nm


-14.0 dBm


-8.0 dBm


-28.2 dBm

Overload power

-8.0 dBm

Optical fiber type

Single-mode

Table A-4 Attributes of 1000M CSFP optical modules Attributes

Description


10 km

Transmitting center wavelength

1490 nm

Receiving center wavelength

1310 nm


-9.0 dBm


-3.0 dBm


-19.5 dBm

Overload power

-3.0 dBm

Optical fiber type

Single-mode

A.3 Interface Attributes of 1000Base-X-SFP Table A-5 lists the interface attributes of 1000Base-X-SFP. Table A-5 Interface attributes of the 1000Base-X-SFP

Issue 02 (2011-09-10)

Attributes

Description

Connector type

LC/PC


Compliant with the selected SFP optical module. (For the attributes of SFP modules, see Table A-6 and Table A-7.)

Working mode

Full-duplex

Frame format



114



Attributes

Description

Network protocol

IP

Table A-6 Attributes of 1000M SFP optical modules Attributes

Description


0.55 km

10 km

40 km

40 km

80 km

100 km

Center wavelength

850 nm

1310 nm

1310 nm

1550 nm

1550 nm

1550 nm


-9.5 dBm

-9.5 dBm

-4.5 dBm

-4.0 dBm

-2.0 dBm

0 dBm


-2.5 dBm

-3.0 dBm

3.0 dBm

1.0 dBm

5.0 dBm

5.0 dBm


-17.0 dBm

-20.0 dBm

-22.5 dBm

-21.0 dBm

-23.0 dBm

-30.0 dBm

Overload power

0 dBm

-3.0 dBm

-3.0 dBm

-3.0 dBm

-3.0 dBm

-9.0 dBm

Optical fiber type

Multimode

Singlemode

Singlemode

Singlemode

Singlemode

Singlemode

Table A-7 Attributes of 1000M colorized optical modules

Issue 02 (2011-09-10)

Attributes

Description


70 km

70 km

70 km

70 km

70 km

70 km

70 km

70 km

Center wavelength

1470 nm

1490 nm

1510 nm

1530 nm

1550 nm

1570 nm

1590 nm

1610 nm


0 dBm

0 dBm

0 dBm

0 dBm

0 dBm

0 dBm

0 dBm

0 dBm


5 dBm

5 dBm

5 dBm

5 dBm

5 dBm

5 dBm

5 dBm

5 dBm


-23.0 dBm

-23.0 dBm

-23.0 dBm

-23.0 dBm

-23.0 dBm

-23.0 dBm

-23.0 dBm

-23.0 dBm

Overload power

0 dBm

0 dBm

0 dBm

0 dBm

0 dBm

0 dBm

0 dBm

0 dBm


115



Attributes

Description

Optical fiber type

Single -mode

Singlemode

Singlemode

Singlemode

Singlemode

Single -mode

Singl emode

Single -mode

A.4 Interface Attributes of 10GBase LAN/WAN-XFP The interface attributes of 10GBase LAN/WAN-XFP see Table A-8. Table A-8 Interface attributes of the 10GBase LAN/WAN-XFP Attributes

Description

Connector type

LC/PC


Compliant with the selected XFP optical module. (For the attributes of XFP modules, see Table A-9.)

Working mode

Full-duplex

Frame format


Network protocol

IP

Table A-9 Attributes of 10G XFP optical modules

Issue 02 (2011-09-10)

Attributes

Description


0.3 km

10 km

40 km

80 km

Center wavelength

850 nm

1310 nm

1550 nm

1550 nm


-7.3 dBm

-6.0 dBm

-1.0 dBm

0 dBm


-1.3 dBm

-1.0 dBm

2.0 dBm

4.0 dBm


-7.5 dBm

-11.0 dBm

-15.0 dBm

-24.0 dBm

Overload power

-1.0 dBm

0.5 dBm

-1.0 dBm

-7.0 dBm

Optical fiber type

Multi-mode

Single-mode

Single-mode

Single-mode


116



A.5 Interface Attributes of 10GBase LAN-SFP+ The interface attributes of 10GBase LAN-SFP+ see Table A-10. Table A-10 Interface attributes of the 10GBase LAN-SFP+ Attributes

Description

Connector type

LC/PC


Compliant with the selected SFP+ optical module. (For the attributes of SFP+ modules, see Table A-11.)

Working mode

Full-duplex

Frame format


Network protocol

IP

Table A-11 Attributes of 10GBase SFP+ optical modules Attributes

Description


0.3 km

10 km

40 km

Center wavelength

850 nm

1310 nm

1550 nm


–7.3 dBm

–8.2 dBm

–4.7 dBm


–1 dBm

0.5 dBm

4.0 dBm


–11.1 dBm

–12.6 dBm

–14.1 dBm

Overload power

–1.0 dBm

0.5 dBm

0.5 dBm

Optical fiber type

Multi–mode

Single–mode

Single–mode

A.6 Interface Attributes of OC-3c/STM-1c cPOS-SFP Table A-12 lists the interface attributes of OC-3c/STM-1 cPOS-SFP.

Issue 02 (2011-09-10)


117



Table A-12 Interface attributes of the OC-3c/STM-1 cPOS-SFP Attributes

Description

Connector type

LC/PC


Compliant with the selected SFP optical module. (For the attributes of SFP modules, see Table A-13.)

Working mode

Full-duplex

Link protocol

PPP ,MP , HDLC and cRTP

Network protocol

IP


Description


2 km

15 km

40 km

80 km

Center wavelength

1310 nm

1310 nm

1310 nm

1550 nm


-19.0 dBm

-15.0 dBm

-5.0 dBm

-5.0 dBm


-14.0 dBm

-8.0 dBm

0 dBm

0 dBm


-30.0 dBm

-31.0 dBm

-37.0 dBm

-37.0 dBm

Overload power

-14.0 dBm

-8.0 dBm

-10.0 dBm

-10.0 dBm

Optical fiber type

Multi-mode

Single-mode

Single-mode

Single-mode

A.7 Interface Attributes of OC-3c/STM-1c POS-SFP Table A-14 lists the interface attributes of OC-3c/STM-1c POS-SFP. Table A-14 Interface attributes of the OC-3c/STM-1c POS-SFP

Issue 02 (2011-09-10)

Attributes

Description

Connector type

LC/PC


118



Attributes

Description



Working mode

Full-duplex

Link protocol

PPP and HDLC

Network protocol

IP


Description


2 km

15 km

40 km

80 km

Center wavelength

1310 nm

1310 nm

1310 nm

1550 nm


-19.0 dBm

-15.0 dBm

-5.0 dBm

-5.0 dBm


-14.0 dBm

-8.0 dBm

0 dBm

0 dBm


-30.0 dBm

-31.0 dBm

-37.0 dBm

-37.0 dBm

Overload power

-14.0 dBm

-8.0 dBm

-10.0 dBm

-10.0 dBm

Optical fiber type

Multi-mode

Single-mode

Single-mode

Single-mode


Issue 02 (2011-09-10)

Attributes

Description

Connector type

LC/PC




119



Attributes

Description

Working mode

Full-duplex

Link protocol

PPP and HDLC

Network protocol

IP


Description


15 km

40 km

80 km

Center wavelength

1310 nm

1310 nm

1550 nm


-15.0 dBm

-3.0 dBm

-3.0 dBm


-8 dBm

2.0 dBm

2.0 dBm


-31.0 dBm

-30.0 dBm

-30.0 dBm

Overload power

-8.0 dBm

-8.0 dBm

-8.0 dBm

Optical fiber type

Single-mode

Single-mode

Single-mode


Issue 02 (2011-09-10)

Attributes

Description

Connector type

LC/PC



Working mode

Full-duplex

Link protocol

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

120



Attributes

Description

Network protocol

IP

Table A-19 Attributes of 2.5G SFP optical modules Attributes

Description


2 km

15 km

40 km

80 km

Center wavelength

1310 nm

1310 nm

1310 nm

1550 nm


-10.0 dBm

-5.0 dBm

-2.0 dBm

-2.0 dBm


-3.0 dBm

0 dBm

3.0 dBm

3.0 dBm


-21.0 dBm

-21.0 dBm

-30.0 dBm

-30.0 dBm

Overload power

-3.0 dBm

0 dBm

-9.0 dBm

-9.0 dBm

Optical fiber type

Multi-mode

Single-mode

Single-mode

Single-mode

A.10 Interface Attributes of OC-192c/STM-64c POS-XFP Table A-20 lists the interface attributes of OC-192c/STM-64c POS-XFP. Table A-20 Interface attributes of the OC-192c/STM-64c POS-XFP

Issue 02 (2011-09-10)

Attributes

Description

Connector type

LC/PC


Compliant with the selected XFP optical module. (For the attributes of XFP modules, see Table A-21.)

Working mode

Full-duplex

Link protocol

PPP and HDLC

Network protocol

IP


121



Table A-21 Attributes of 10G XFP optical modules Attributes

Description


10 km

40 km

80 km

Center wavelength

1310 nm

1550 nm

1550 nm

Minimum -6.0 dBm transmitting power

-1.0 dBm

0 dBm

Maximum -1.0 dBm transmitting power

2.0 dBm

4.0 dBm


-11.0 dBm

-15.0 dBm

-24.0 dBm

Overload power

0.5 dBm

-1.0 dBm

-7.0 dBm

Optical fiber type

Single-mode

Single-mode

Single-mode

The 10G XFP multi-mode optical transceiver supports two types of multi-mode optical fibers with different cores. Table A-22 lists the relationship between the core, the modal/bandwidth, and the transmission distance. During configuration, the length of optical fibers is restricted by the transmission distance. In addition, the optical fiber with the 50-um core and 2000-MHz*km modal/bandwidth is a special type, which is not delivered by Huawei. If this type of optical fibers are required, you need to purchase it additionally. Table A-22 The transmission distance of 10G XFP optical modules Core Fiber(μm)

Modal/Bandwidth (Mhz*km)

Transmission distance (m)

50

2000

2~300

50

500

2~82

62.5

200

2~33

A.11 Interface Attributes of OC-3c/STM-1c ATM-SFP Table A-23 lists the interface attributes of the OC-3c/STM-1c ATM-SFP. Table A-23 Interface attributes of the OC-3c/STM-1c ATM-SFP

Issue 02 (2011-09-10)

Attributes

Description

Connector type

LC/PC


122



Attributes

Description



Working mode

Full-duplex

Link protocol

IPoA

Network protocol

IP


Description


2 km

15 km

40 km

80 km

Center wavelength

1310 nm

1310 nm

1310 nm

1550 nm


-19.0 dBm

-15.0 dBm

-5.0 dBm

-5.0 dBm


-14.0 dBm

-8.0 dBm

0 dBm

0 dBm


-30.0 dBm

-31.0 dBm

-37.0 dBm

-37.0 dBm

Overload power

-14.0 dBm

-8.0 dBm

-10.0 dBm

-10.0 dBm

Optical fiber type

Multi-mode

Single-mode

Single-mode

Single-mode

A.12 Interface Attributes of OC-12c/STM-4c ATM-SFP Table A-25 lists the interface attributes of the OC-12c/STM-4c ATM-SFP. Table A-25 Interface attributes of the 2-port OC-12c/STM-4c ATM-SFP FPIC

Issue 02 (2011-09-10)

Attributes

Description

Connector type

LC/PC

Optical interface attributes

Compliant with the selected SFP optical module. (For the attributes of SFP modules, see Table A-26)


123



Attributes

Description

Working mode

Full-duplex

Link protocol

IPoA

Network protocol

IP

Table A-26 Attributes of 622M SFP optical modules

Issue 02 (2011-09-10)

Attributes

Description


15 km

40 km

80 km

Center wavelength

1310 nm

1310 nm

1550 nm


-15.0 dBm

-3.0 dBm

-3.0 dBm


-8 dBm

2.0 dBm

2.0 dBm


-31.0 dBm

-30.0 dBm

-30.0 dBm

Overload power

-8.0 dBm

-8.0 dBm

-8.0 dBm

Optical fiber type

Single-mode

Single-mode

Single-mode


124

Commission Guide(V600R003C00 02)

Recommend Documents