zte

PrefaceMaintenance ExperienceEditorial Committee

Maintenance ExperienceNewsroom

Address: ZTE Plaza, Keji Road South, Hi-Tech

Industrial Park, Nanshan District,

Shenzhen, P.R.China

Postal code: 518057

Contact: Song Chunping

Tel: +86-755-26770600, 26771195

Fax: +86-755-26772236

Document Support Email: [email protected]

Technical Support Website: http://ensupport.zte.

com.cn

Maintenance ExperienceBimonthly for Data ProductsNo.6 Issue 153, February / 2009

Director: Qiu Weizhao

Deputy Director: Chen Jianzhou

Editors:Jiang Guobing, Zhang Shoukui, Wu Feng, Yuan

Yufeng, Tang Hongxuan, Li Gangyi, Song Jianbo,

Tian Jinhua, Wang Zhaozheng, Liu Wenjun,

Wang Yapping, Lei Kun, Wang Tiancheng,

Ge Jun, Yu Qing, Zhang Jiebin, Fang Xi

Technical Senior Editors:Hu Jia, Bai Jianwen

Executive Editor:Zhang Fan

In this issue of ZTE's "Maintenance Experience", we continue to pass on various field reports and resolutions that are gathered by ZTE engineers and technicians around the world.

The content presented in this issue is as below:One Special Document

Five Maintenance Cases of ZTE's Data Products

Have you examined your service polices and procedures lately? Are you confident that your people are using all the tools at their disposal? Are they trained to analyze each issue in a logical manner that provides for less downtime and maximum customer service? A close look at the cases reveals how to isolate suspected faulty or mis-configured equipment, and how to solve a problem step by step, etc. As success in commissioning and service is usually a mix of both discovery and analysis, we consider using this type of approach as an example of successful troubleshooting investigations.

While corporate leaders maintain and grow plans for expansion, ZTE employees in all regions carry out with individual efforts towards internationalization of the company. Momentum continues to be built, in all levels, from office interns to veteran engineers, who work together to bring global focus into their daily work.

If you would like to subscribe to this magazine (electronic version) or review additional articles and relevant technical materials concerning ZTE products, please visit the technical support website of ZTE Corporation (http://ensupport.zte.com.cn).

If you have any ideas and suggestions or want to offer your contributions, you can contact us at any time via the following email: [email protected].

Thank you for making ZTE a part of your telecom experience!

Maintenance Experience Editorial CommitteeZTE CorporationFebruary, 2009

Contents

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

Huang Zhiyan / ZTE Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Failing to Get on-line with Fixed IP Address

Wang Yufeng / ZTE Corporation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

IP Address Pool Configuration

Liu Peng / ZTE Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Link Aggregation Configuration on UAS2500S

Li Yong / ZTE Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Processing of IS-IS Malfunction on ZXUAS 10600

Wang Yufeng / ZTE Corporation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

MPLS MP-BGP VPN Configuration

Zhu Yanbo / China Unicom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Maintenance Experience2

February 2009 Issue 153

1 ZXUAS 10800E Hardware CheckZXUAS 10800E hardware check

includes the following contents.

1.1 Indicators on Front Panel of Rack

1.1.1 Checking ContentCheck whether the indicators of

BUPC3 (BUPC) board, BSFC3 board,

BNPCH board and BNPCIX board on

the front panel of ZXUAS 10800E rack

are normal. For description convenience,

BUPC3 board is mentioned in the following

contents. ZXUAS 10800E also supports

BUPC board.

1.1.2 Normal SituationRUN indicators of the boards flash with

the same frequency, that is, once every

second. No ALM indicator is on. MST

indicators of active BUPC3 board and

active BSFC3 board are constantly on.

OFF indicators of standby BUPC3 board

and standby BSFC3 board are constantly

on. If the track line clock is configured,

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server⊙ Huang Zhiyan / ZTE Corporation

TRACK indicators of active and standby BSFC3

boards are constantly on (the indicators may flash

according to line clock status).

1.1.3 Abnormal SituationALM indicator of active BUPC3 board is

constantly on.

ALM indicator of BNPCIX/BNPCH board is

constantly on.

Four indicators of BNPCH/BNPCIX board flash

at random.

1.1.4 Abnormal Situation ProcessingWhen the ALM indicator of active BUPC3 board

is constantly on, check whether the services are

normal. If the services are abnormal, telnet to the

device and view the display results with show run

command and show ip route command. If services

and display results are abnormal, this indicates

that there is a software fault on the active BUPC3

board. It is necessary to change over to the

standby BUPC3 board by pressing EXCH button

on the active BUPC3 board and reset the active

Key words: ZXUAS, 10600, 10800E, routine maintenance

Data Products

www.zte.com.cn

3

BUPC3 board in time.

When the ALM indicator of BNPCIX/BNPCH

board is constantly on, this indicates that there

is a fault on corresponding interface card. Reset

the BNPCIX/BNPCH board. If the indicator does

not recover to normal situation, it is necessary

to change the corresponding interface card or

BNPCIX/BNPCH board.

When indicators of BNPCH/BNPCIX board

flash at random, this indicates that the board is

resetting automatically. Observe whether the

indicators can recover to normal situation. If the

indicators fail to recover to normal situation, it is

necessary to change the corresponding interface

card or BNPCIX/BNPCH board.

Check whether a system hal ted f i le is

generated.

1.2 Indicator of BIC Card1.2.1 Checking Content

Check whether the indicator of BIC card on the

back panel of ZXUAS 10800E rack is normal.

1.2.2 Normal SituationRUN indicator (green) is on, and ALM indicator

(red) is off.

1.2.3 Abnormal SituationALM indicator of BIC card is constantly on.

1.2.4 Abnormal Situation ProcessingWhen ALM indicator of BIC card is constantly

on, this indicates that the rack does not obtain any

alarm information about related environment. This

does not affect the normal running of the device.

1.3 Indicators of Interface Cards1.3.1 Checking Content

Check whether the indicators of interface cards

on back panel of ZXUAS 10800E rack are normal.

1.3.2 Normal SituationRUN indicators (green) are on, and ALM

indicators (red) are off (indicators of interface cards

are below NP panel).

1.3.3 Abnormal SituationALM indicators of interface cards are

constantly on.

1.3.4 Abnormal Situation ProcessingWhen the ALM indicator of an interface

card is constantly on, this indicates that

there is a fault on the interface card.

If services are not affected, reset the

interface card when services are not busy

(reset the corresponding BNPCIX/BNPCH

board).

Check whether a system halted file is

generated.

2 ZXUAS 10600 Hardware CheckZXUAS 10600 ha rdware check


2.1 Indicators on Front Panel of Rack

2.1.1 Checking ContentsCheck whether the indicators of BUPC

board, BSFC board and BNPCT board on

the front panel of ZXUAS 10600 rack are

normal.

2.1.2 Normal SituationRUN indicators of the boards flash

with the same frequency, that is, once

every second. No ALM indicator is on.

MST indicators of active BUPC board and

active BSFC board are constantly on. OFF

indicators of standby BUPC board and

standby BSFC3 board are constantly on. If

the track line clock is configured, TRACK

indicators of active and standby BSFC

boards are constantly on (the indicators

may flash according to line clock status).

2.1.3 Abnormal SituationALM indicator of active BUPC board is

constantly on.

ALM indicator of BNPCT board is

constantly on.


Routine Maintenance of ZXUAS 10600&10800E Broadband Access ServerFebruary 2009 Issue 153

Four indicators of BNPCT board flash

at random.

2.1.4 Abnormal Situation ProcessingWhen the ALM indicator of active

BUPC board is constantly on, check

whether the services are normal. If the

services are abnormal, telnet to the device

and view the display results with show run

command and show ip route command. If

services and display results are abnormal,

this indicates that there is software fault on

the active BUPC board. It is necessary to

change over to the standby BUPC board

by pressing EXCH button on the active

BUPC board and reset the active BUPC

board in time.

When the ALM indicator of BNPCT

board is constantly on, this indicates that

there is fault on corresponding interface

card. Reset the BNPCT board. If the

indicator does not recover to normal

situation, it is necessary to change the

corresponding interface card or BNPCT

board.

When indicators of BNPCT board flash

at random, this indicates that the board is

resetting automatically. Observe whether

the indicators can recover to normal

situation. If the indicators fail to recover

to normal situation, it is necessary to

change the corresponding interface card

or BNPCT board.

Check whether a system halted file is

generated.

2.2 Indicator of BIC Card2.2.1 Checking Content

Check whether the indicator of BIC

card on the back panel of ZXUAS 10600

rack is normal.

2.2.2 Normal SituationRUN indicator (green) is on, and ALM

indicator (red) is off.

2.2.3 Abnormal SituationALM indicator of BIC card is constantly on.

2.2.4 Abnormal Situation ProcessingWhen ALM indicator of BIC card is constantly

on, this indicates that the rack does not obtain any

alarm information about related environment. This

does not affect the normal running of the device.

2.3 Indicators of Interface Cards2.3.1 Checking Content

Check whether the indicators of interface cards

on back panel of ZXUAS 10600 rack are normal.

2.3.2 Normal SituationRUN indicators (green) are on, and ALM

indicators (red) are off (indicators of interface cards

are below NP panel).

2.3.3 Abnormal SituationALM indicators of interface cards are constantly

on.

2.3.4 Abnormal Situation ProcessingWhen the ALM indicator of an interface card is

constantly on, this indicates that there is fault on

the interface card. If services are not affected, reset

the interface card when services are not busy (reset

the corresponding BNPCT board).

Check whether a system hal ted f i le is

generated.

3 System Running CheckSystem running check includes the following

contents.

3.1 Configuration Information3.1.1 Checking Content

Configuration information on device is viewed

with show run command.

3.1.2 Normal SituationIn normal situation, the following information (or

similar information) is displayed. The information is

complete, and it is consistent with the contents that

are configured by users.

Data Products

www.zte.com.cn

5

ZXUAS#show runBuilding configuration...Current configuration:!version V4.6.01!enable secret 5 RcMLuUKvnFZX9kNAV6A/UA==!nvram mng-ip-address 168.1.9.8 255.255.0.0!nvram boot-username target!nvram boot-password target!nvram boot-server 168.1.88.2!nvram default-gateway 10.40.89.25!nvram imgfile-location local!hostname ZXUAS!username ZXUAS password ZXUAS!user-authentication-type local!snmp-server contact +86-21-68895000-189572snmp-server location No.889 bibo Rd. pudong District, Shanghai, Chinasnmp-server packetSize 1400snmp-server engine-id 830900020300010289d64401snmp-server view DefaultView system includedsnmp-server view AllView internet included!logging onlogging buffer 200logging mode FULLCYCLElogging console NOTIFICATIONSlogging level NOTIFICATIONS!line console idle-timeout 120……

3.1.3 Abnormal SituationConfiguration information displayed on

device is incomplete.

Configuration information displayed is

not consistent with the content that users

configured.

3.1.4 Abnormal Situation ProcessingWhen conf igurat ion in format ion

displayed on device is incomplete, check

whether the services are normal. If the

services are normal, change the login

mode. If serial port login mode is used,

make sure that the login software is Hyper

Terminal attached in WINDOW operating

system. Change the PC and retry. If

configuration information displayed on

device is still incomplete, use TELNET

login mode to view the configuration

information. If the display result is still

incomplete after the above operations,

this indicates that there may be fault

of software. Contact to ZTE customer

support center for further processing.

When conf igurat ion in format ion

displayed is not consistent with the

commands configured by users manually,

check whether the commands configured

by users have taken effect or not. If

the commands do not take effect, re-

configure them. If the commands have

taken effect but are not displayed, look up

in command manuals to check whether

the configuration is default (default

configuration is not displayed in result of

show run command). If the commands

have taken effect but the display result is

not consistent with the content that users

configured, this indicates that there may

be a display problem about the version.

Feed back this situation to ZTE customer

support center.



3.2 Interface Information3.2.1 Checking Content

View interface status with show ip

interface brief command.

3.2.2 Normal SituationIn normal situation, the following

information (or similar information) is

displayed. The statuses of interface must

be up.

the configuration of other parameters. For the

detailed configuration, refer to command manuals.

If the problem still exists, contact to ZTE customer


3.3 Port Traffic3.3.1 Checking Content

Viewing port traffic is to check whether traffic on

related port is normal. Traffic abnormity can cause

traffic congestion on port, which will affect normal

services. To view port traffic, use show interface

<interface-name> command.

3.3.2 Normal SituationIn normal situation, the following information is

displayed, indicating normal traffic on the port.

ZXUAS#show interface fei_1/7

fei_1/7 is up, line protocol is up

MAC address is 00d0.d0c0.00e0

Internet address is 10.0.0.1/16

Description is none

MTU 1500 bytes BW 100000 Kbits

Syslog send disable

Last clearing of "show interface" counters

never

300 seconds input rate 986433 Bps,

5984 pps

300 seconds output rate 1588616 Bps,

2426 pps

Interface peak rate : input 3336705 Bps,

output 9655627 Bps

Interface utilization: input 7%, output

12%

Input:

Packets : 18856871211 Bytes:

3577239232421

Unicasts : 4212281941 Multicasts: 15482672

Broadcasts: 1744204710

64B : 765621284 65-127B : 3457875708

128-255B : 144996806

256-511B : 168083086 512-1023B :

548572994 1024-1518B: 1072082442

ZXUAS#show ip interface brief

interface IP-Address Mask AdminStatus PhyStatus Protocol

gei_3/1 unassigned unassigned up up up

gei_3/1.1 172.31.129.1 255.255.255.252 up up up

gei_3/2 unassigned unassigned up down down

loopback1 211.95.168.135 255.255.255.255 up up up

3.2.3 Abnormal SituationAdminStatus is down, Protocol is down

and PhyStatus is up.

PhyStatus is down, Protocol is down

and AdminStatus is up.

AdminStatus and PhyStatus are up,

and Protocol is down.

3.2.4 Abnormal Situation ProcessingWhen AdminStatus is down, Protocol

is down and PhyStatus is up, this indicates

that physical connection is normal. The

corresponding interface may be shut

down. Enter interface configuration mode

and input no shut command.

When PhyStatus is down, Protocol

is down and AdminStatus is up, this

indicates that there is a problem on

physical connection. Check the physical

connection.

When AdminStatus and PhyStatus

are up, and Protocol is down, check

c o n f i g u r a t i o n i n f o r m a t i o n o n t h e

interface. Parameters may be configured

incorrectly or the parameters are not

configured. Meanwhile, pay attention to

Data Products

www.zte.com.cn

7

Undersize: 0 Oversize : 5 CRC-

ERROR : 14

Output:

Packets : 8123619305 Bytes:

4636044787350

Unicasts : 3392041984 Mul t icasts: 0

Broadcasts: 436610025

64B : 452201789 65-127B : 3840983938

128-255B : 436380539

256-511B : 236397752 512-1023B :

636055401 1024-1518B: 2521647643

Oversize : 0

3.3.3 Abnormal SituationIn abnormal situation, interface utilization

reaches 80%~90%.

If users view the port traffic with show interface

command for several times, the result shows that

the number of broadcast messages increases

rapidly.

3.3.4 Abnormal Situation ProcessingIf interface utilization reaches 80%~90% but

the number of broadcast messages does not

increase rapidly when users view the port traffic

with show interface command for several times,

this indicates that the network traffic is large and it

is necessary to extend the capacity. There are two

recommendations:

Extend the capacity of current network. Add

some devices or egresses to implement load

balancing.

If there is no condition to extend the capacity,

implement speed limit to users on access layer

to ease network congestion.

If the number of broadcast messages increases

rapidly when users view the port traffic with show

interface command for several times, check

whether the services are normal. If the services are

not normal, view the alarm information. If there are

a lot of alarms for drifting of different IP addresses,

there may be broadcast storm in lower network or

virus attacks. Check the network connecting to this

port, and make sure that there is no loop,

or find out the attack source by port traffic

and MAC address on device of lower layer.

3.4 Utilization of CPU and Memory3.4.1 Checking Content

To view utilization of CPU and memory,

use show process command in privilege

mode.

3.4.2 Normal SituationTake ZXUAS 10600 as an example.

The following information is displayed.

ZXUAS#show process

CPU 5s 30s 2m 30s max total memory buffer

utility utility utility utility memory utility utility

RPU 2 0% 0% 0% 23% 512M 46% 0%

MPU 2 0% 0% 0% 90% 512M 30% 0%

SFC 2 2% 2% 2% 8% 64M 59% 0%

NPC 1 0% 1% 6% 50% 101M 84% 0%

NPC 3 0% 0% 0% 53% 101M 84% 0%

NPC 7 0% 0% 7% 53% 101M 84% 0%

NPC 8 0% 0% 1% 60% 101M 84% 0%

In normal situation, CPU utilization

sampled at 5s, 30s and 2m must not be

more than 50%.

3.4.3 Abnormal SituationCPU uti l ization is high, reaching

80%~90%.

3.4.4 Abnormal Situation ProcessingIf CPU utilization keeps 80%~90%,

check whether services are normal.

Generally, CPU utilization of 80%~90%

or higher will affect normal services at a

certain extent. Check the log information of

the device. For ZXUAS 10600 and ZXUAS

10800E, find out the BNPC board of which

the CPU utilization keeps high and reset

the board. Wait a moment to observe

whether the CPU utilization recovers to a



normal value. If CPU utilization does not

recover, there may be virus attacks in the

network. View log information and find

out the attack source, and contact to ZTE

customer support center for help as soon

as possible.

3.5 Routing Table3.5.1 Checking Content

Check whether routing table is normal

by configuring show ip route command

and show ip protocol routing summary

command in privilege mode.

3.5.2 Normal SituationThere are different types of route

items. When users use show ip protocol

routing summary command to view the

routing table for several times, the number

of route items is steady.

3.5.3 Abnormal SituationWhen users use show ip protocol

routing summary command to view the

routing table for several times, dynamic

route item changes frequently.

Route items are not learnt correctly.

The route items that must be learnt are not

learnt.

3.5.4 Abnormal Situation ProcessingI f dynamic rou te i t ems change

f requent ly when users use show ip

protocol routing summary command

to view the routing table for several

times, this indicates that there is a route

dampening in the network. Packets may

be lost in the network, and the network

may be through for a moment and be

blocked for a moment. It is necessary

to check the detailed configuration of

protocols.

If route items are not learnt correctly,

check the current route configuration

on the device and the configuration on

the peer device. If there is no problem about

configuration, contact to ZTE customer support

center for further processing.

3.6 System Log3.6.1 Checking Content

To view the system log information, use show

logging alarm command in privilege mode.

3.6.2 Normal SituationIn normal situation, the following information (or

similar information) is displayed. There are some

alarms indicating the port state (UP/DOWN), but

there is no serious system alarm.

ZXUAS#show logging alarm

An alarm 18439 level 5 occurred at 16:19:36

10/25/2003 UTC sent by UPC(MPU) 2 %TCP:

tcp rcv bad checksum

description:


10/25/2003 UTC sent by UPC(MPU) 2 %UDP:

udp rcv packet has a invalid checksum

description:


10/27/2003 UTC sent by NPC 4 %IP: Time out

while reassemble IP datagram

3.6.3 Abnormal SituationAbnormal alarm information is displayed.

Abnormal Situation ProcessingCommon log items and their descriptions are

given below.

description: Port Down port fei_1/8

This indicates the course of a physical port

from through to off. Pay attention to this alarm

information if it is not caused by man.

description: udp rcv packet has a invalid

checksum

This indicates that the checksum of received

UDP message is invalid. Generally, such alarm

information appears due to the unpredictability of

user actions. It can be ignored temporarily.

Data Products

www.zte.com.cn

9

description: tcp rcv bad checksum

This indicates that the checksum of received

TCP message is invalid. Generally, such alarm

information appears due to the unpredictability of

user actions. It can be ignored temporarily.

description: Time out while reassemble IP

datagram

This indicates that IP messages time out

during recombination. Pay attention to this alarm

information when there is a lot of this alarm

information. In this situation, the device may be

attacked by fragmentation packets. It is necessary

to check the CPU utilization and packet processing

statistical information of NP in unit time. If the CPU

utilization keeps a high value, or the number of

fragmentation packets received by NP reaches the

set limit, the device is being attacked. This may

block the normal services, decreasing the network

speed of users and making users off-line. Please

contact to ZTE customer support center for help.

There may be other alarm information. If

users can not understand the meaning and

perniciousness of the alarm information, please

contact to ZTE customer support center.

3.7 Dial-up Service3.7.1 Checking Content

Users implement PPP dial-up in radius

authentication mode, local authentication mode

and none authentication mode.

3.7.2 Normal SituationIn radius authentication mode, users can pass

the authentication with correct user name and

password. When users use incorrect user name

and password, No. 691 error information will

appear.

In local authentication mode, users can pass

the authentication with the locally configured

user name and password. When users use

incorrect user name and password, No. 691 error

information will appear.

In none authentication mode, users can pass

the authentication with any non-mull user

name and password.

Abnormal SituationUsers can not pass authentication with

correct user name and password.

No. 691 error information appears.

No. 678 error information appears.

Abnormal Situation ProcessingCheck the connectivity of network and

terminal devices.

Check whether the configuration of

UAS device for user access and user

domain management is correct.

Check whether the user account is

legal.

Check whether the communication with

AAA server is normal.

Check whe the r t he IP add ress

resource of the device is enough.

If the problem still can not be solved,

please contact to ZTE customer support


3.8 Fixed IP Service3.8.1 Checking Content

Check whether users with fixed IP

addresses can get on-line normally.

3.8.2 Normal SituationUsers with fixed IP addresses can get

on-line normally after the configuration of

IP addresses manually.

3.8.3 Abnormal SituationUsers with fixed IP addresses can not

get on-line after the configuration of IP

addresses manually.

3.8.4 Abnormal Situation ProcessingCheck whether the configuration of ip-

host is correct.

Check whether the VLAN configuration

on the sub-interface connecting to users is

correct.

Check whether the VBUI binding on



the sub-interface connecting to users is

correct.

Check the down-link device to see

whether the user is in the right VLAN.

Check whether the static ARP binding

is configured between the UAS device and

client.

Check whether the IP address, network

gateway and DNS on user terminal are

configured correctly.




3.9 DHCP Service3.9.1 Checking Content

Check whether users can obtain IP

addresses through DHCP.

3.9.2 Normal SituationUsers can obtain IP addresses through

DHCP and get on-line normally.

3.9.3 Abnormal SituationUsers can not obtain IP addresses

through DHCP, or they can not get on-

line after obtaining IP addresses through

DHCP.

3.9.4 Abnormal Situation ProcessingCheck whether DHCP configuration is

correct.

Check whether the user is in the

correct VLAN.

C h e c k w h e t h e r t h e c l i e n t i s

configured to forbid obtaining IP address

automatically.

If the user can obtain IP address

through DHCP but fails to get on-line,

check whether l imit access policy is

configured.

Check whe the r co r rec t DNS i s

distributed to the user.




3.10 VPDN Service3.10.1 Checking Content

Check whether VPDN users can dial up

normally.

3.10.2 Normal SituationVPDN users can dial up normally.

3.10.3 Abnormal SituationVPDN users can not dial up normally.

3.10.4 Abnormal Situation ProcessingCheck whether L2TP conf igurat ion and

configuration of parameters provided by LNS end

are correctly.

Check whether a tunnel can be established

normally between LAC and LNS.

Check the authentication result of PPP user at

LNS end.

If dynamic VPDN is configured, it is only

required to input vpdn enable command in global

configuration mode. If there is No.691 error

information, check the configuration of radius and

LNS.

If the problem still can not be solved, please

contact to ZTE customer support center for further

processing.

3.11 Radius Butt Joint3.11.1 Checking Content

Check whether the communication with Radius

server is normal.

3.11.2 Normal SituationIn normal situation, the UAS device can ping

to Radius authentication server and accounting

server successfully with radius-ping accounting-

group command and radius-ping authentication-

group command. Users can pass authentication

with correct user name and password, and they are

accounted normally.

3.11.3 Abnormal SituationThe UAS device can not communicate with

Radius server.

Authentication state or accounting state is

abnormal.

Data Products

www.zte.com.cn

11

3.11.4 Abnormal Situation ProcessingCheck whether the routes from the UAS device

to Radius server are reachable and unblocked.

Check whether the butted parameters to Radius

server on UAS device are configured correctly.

Check whether the Radius server can identify

UAS devices correctly.

If the problem still can not be solved, please

contact to ZTE customer support center for further

processing.

4 System Abnormity ProcessingSystem abnormity processing includes the

following contents.

4.1 Start up Device Failure4.1.1 Checking Content

Check device startup.

4.1.2 Normal SituationUAS device can be started up from FLASH

normally.

4.1.3 Abnormal SituationUAS device can not be started up from FLASH

normally.

4.1.4 Abnormal Situation ProcessingIt costs 10 minutes to start up ZXUAS 10600

or ZXUAS 10800E. If the UAS device can not

finish startup after 10 minutes, this indicates that

abnormity appears on the device. Use serial port

to connect the CONSOLE port on the UAS device

and collect startup information. If there is saved

version, enter BOOT mode to implement network

startup and observe whether the UAS device can

be started normally. If the UAS device still can not

be started normally, pull out a BUPC board (usually

there are two BUPC boards, one for active and

the other for standby) and use the standby BUPC

board as active board to start up. Meanwhile,

prepare another BUPC board for standby and

contact to ZTE customer support center. ZXUAS

10800E also supports BUPC3 board.

4.2 Device Memory Abnormal Utilization4.2.1 Checking Content

Check memory utilization with show

process command in global configuration

mode for several times.

4.2.2 Normal SituationMemory utilization is steady, no more

than 80%.

4.2.3 Abnormal SituationMemory ut i l izat ion is abnormal ,

reaching 80%~90%, even more than

90%. If users check memory utilization for

several times, the memory utilization is

increasing.

4.2.4 Abnormal Situation ProcessingIf the memory utilization is increasing,

this indicates that there may be software

fault on the device that causes memory

leak. Please contact to ZTE customer


4.3 CONSOLE Port Log in Failure4.3.1 Checking Content

Use serial port on PC to connect

CONSOLE port to log in to UAS device.

4.3.2 Normal SituationUsers can use serial port on PC to

connect CONSOLE port to log in to UAS

device and check running information on

the device.

4.3.3 Abnormal SituationUsers can not use serial port on PC to

connect CONSOLE port to log in to UAS

device, or there is messy code displayed.

4.3.4 Abnormal Situation ProcessingWhen users can not log in to the UAS

device through CONSOLE port, check the

configuration cable. It is recommended to

use the configuration cable delivered with

the device. For configuration cables of

other venders, although the appearances



are the same, but the internal line orders

are different.

Check the serial port configuration on

user terminal. Make sure that the serial

port configuration on user terminal meets

the requirements in user manual. If there

is messy code displayed, it may be caused

by unmatched baud rate. On terminal of

ZXUAS 10600 and ZXUAS 10800E, baud

rate must be 9600, data bits must be 8,

parity must be none and stop bits must be 1.

If the above configuration is correct,

check the login software on the terminal.

If third-party software is used, try to use

another kind of software to log in. It is

recommended to use Hyper Terminal

attached in WINDOW operating system.

If users log in to UAS device through

USB interface and conversion line, the

compatibility of the conversion line can

cause problem. It is recommended to

change a terminal that has serial port and

connect to UAS device through the serial

port directly.

If the problem still exists after the

above operations, the CONSOLE port

on UAS device may be broken. Please

contact to ZTE customer support center

for further processing.

4.4 Telnet Log in Failure4.4.1 Checking Content

Log in to UAS device through telnet.

4.4.2 Normal SituationWhen routes are through, users can

log in to UAS device through telnet.

4.4.3 Abnormal SituationUsers can ping to UAS successfully,

but they fail to log in to UAS device

through telnet.

4.4.4 Abnormal Situation ProcessingThe possible reasons to cause the

problem and corresponding processing method are

described below.

Reason1: Telnet address is wrong.

Check the telnet address. Make sure that the

address is correct.

Reason2: The number of telnet connections

reaches the upper limit.

ZXUAS device supports up to four telnet

connections at the same time. Check whether

there have been 4 connections on the device with

who command through CONSOLE port. If there

have been four VTYs, delete idle users with clear

tcp vty <number> command and then retry log in to

the device through telnet.

Reason3: User name and password is not

configured.

When users connect to UAS device, there will

be information prompting to input user name and

password. If users fail to log in no matter what

user name and password they input, log in to the

device through CONSOLE port and configure user

name and password with username <username>

password <password>. After the configuration,

retry log in to the device through telnet.

Reason4: Access control of telnet is configured

and the device address is not allowed to be log

in through telnet.

Check the configuration of the UAS device.

Make sure that the UAS device address can be log

in through telnet.

Reason4: UAS device is attacked by TCP

connections.

Check TCP connection information with show

tcp brief command. If there are a lot of connections

to the UAS device from the same address, this

indicates that the UAS device is being attacked

by TCP connections. Configure ACL to filter the

address and establish TCP connections again.

If the problem still exists after the above

operations, please contact to ZTE customer


Data Products

www.zte.com.cn

13

5 Maintenance and Troubleshooting of Ethernet FunctionsMaintenance and troubleshooting of Ethernet

functions include the following contents.

5.1 ARP Function Maintenance5.1.1 Checking Content

Check ARP information with show arp interface

<interface-name> command and check whether the

UAS device can ping to peer devices successfully.

5.1.2 Normal SituationUAS device can learn ARP addresses of peer

devices, and peer devices also can learn the ARP

address of this UAS device. They can ping to each

other successfully.

An example is given below.

ZXUAS# show arp interface <interface-name>

Arp protect whole is disabled . The count is 26.

Address Age(min) Hardware Addr Interface

60.29.39.201 0 00d0.d0c3.becb fei_1/1

60.29.39.202 - 00d0.d0c5.3a80 fei_1/1

221.239.126.49 6 00e0.fc39.af15 fei_3/1

221.239.126.50 - 00d0.d0c5.3a80 fei_3/1

10.1.10.201 4 0012.3f01.2c3d gei_2/2

5.1.3 Abnormal SituationUAS device fails to learn ARP addresses of

peer device.

Peer devices fail to learn the ARP address of

this UAS device.

5.1.4 Abnormal Situation ProcessingWhen UAS device fails to learn ARP addresses

of peer device, perform the following operations.

Check whether the configuration on interface

is correct. Check whether the interface is up with

show ip interface brief command. If the interface is

down, check the interface information and find out

the problem.

If the interface state is normal, check whether

packets are sent and received normally with

show interface command. If there is no broadcast

packet, or the numbers of sent packets

and received packets do not increase and

the number of error packets increases

quickly, check the port traffic to find out the

problem.

If interface state and port traffic are

normal, check debugging information to

observe whether there are ARP broadcast

packets received and whether response

packets are sent normally. If there is no

ARP broadcast packet, there may be

problems on peer devices. Check the

peer devices to find out these problems. If

ARP broadcast packets are received and

response packets are not sent, there may

be software fault on UAS device. Please

contact to ZTE customer support center

for further processing.

When the UAS device is on-line and

there are a lot of users connecting to the

device, debugging will cost wastage of

system resources. It is recommended

to capture packets and then implement

troubleshooting.

When peer devices fail to learn the

ARP address of this UAS device, perform

the following operations.

Check the interface configuration

and interface information on UAS device

and peer devices to observe whether

the problem is caused by interface

configuration or physical link.

Check whether ARP request packets

are sent on UAS device and whether

ARP response packets are sent on peer

devices by capturing packets or debugging

information.

If ARP request packets are not sent

on UAS device, please contact to ZTE

customer support center for further

processing. If ARP response packets are

not sent on peer devices, change a peer



device and test again.


above operations, please contact to

ZTE customer support center for further

processing.

5.2 Aggregating Link Failure5.2.1 Checking Content

Check LACP state with show lacp <id>

internal command.

5.2.2 Normal SituationIn normal situation, Agg State is

selected.

5.2.3 Abnormal SituationIn abnormal situation, Agg State is

unselected.

5.2.4 Abnormal Situation ProcessingCheck whether the configurations on

member interfaces are the same, including

interface speed and duplex mode. If the

problem still exists after the configurations

are modified to the same, please contact

to ZTE customer support center for further

processing.

5.3 Packets Loss after Aggregation5.3.1 Checking Content

Check whether there are packets lost

on the aggregated links.

5.3.2 Normal SituationIn normal situation, users can ping to

destination address successfully and there

is no packet lost.

5.3.3 Abnormal SituationUsers can ping to destination address

successfully but packets are lost.

5.3.4 Abnormal Situation ProcessingC h e c k w h e t h e r C R C E R R O R

increases with show interface command

on the member interfaces.

Disconnect the links in the aggregation

group one by one until there is no packet

lost. This helps to find out the link with

problem.




5.4 DHCP Server Function Abnormity5.4.1 Checking Content

Configure the device to a DHCP server and

then simulate a user to obtain an IP address.

5.4.2 Normal SituationUser can obtain IP address and network

gateway information.

5.4.3 Abnormal SituationUser fails to obtain IP address.

5.4.4 Abnormal Situation ProcessingCheck the operating system of user PC. Make

sure that DHCP client is not forbidden on the PC.

Check whether the configuration of DHCP

server is correct. DHCP server function must be

enabled, interface and IP pool must be configured,

and VLAN property of user interface must be

configured correctly. Check DHCP server process

information with show ip dhcp config command.

Check whether user interface is up.

Check whether IP pool address is distributed

and whether the addresses in the pool are used

up.

Check whether interface at user side is

encapsulated correctly, and whether the interface

is bound to DHCP VBUI.




5.5 DHCP Relay Function Abnormity5.5.1 Checking Content

Configure the device to a DHCP relay and then

simulate a user to obtain an IP address.

5.5.2 Normal SituationUser can obtain IP address and network


5.5.3 Abnormal SituationUser fails to obtain IP address.

Data Products

www.zte.com.cn

15

User can obtain IP address but fail to obtain


5.5.4 Abnormal Situation ProcessingWhen user fails to obtain IP address, perform

the following operations.

Check whether configuration of DHCP server is

correct.

Check whether configuration of DHCP relay is

correct. To check DHCP relay process information,

use show ip dhcp config command.

Check whether the routes are reachable from

DHCP server to the subnet that DHCP agent

locates.

When user can obtain IP address but fail to

obtain gateway information, check whether the

gateway address configured on DHCP server

is the default gateway address for user. If it is,

check whether the address is in the same network

segment with the address DHCP agent.




5.6 Frequent VRRP Active/Standby Changeover

5.6.1 Checking ContentCheck VRRP related information with show vrrp

command.

5.6.2 Normal SituationIn a VRRP group, there is only one master

device, others are backup devices. In normal

situation, the state of VRRP is steady.

5.6.3 Abnormal SituationVRRP active device and standby devices

change over frequently.

5.6.4 Abnormal Situation ProcessingCheck whether the physical links are normal

and whether the contacts are good.

To modify the keep-alive interval to 3 seconds,

use vrrp <group> advertise 3 command.




6 Processing for Broadband Access Service AbnormityProcessing for broadband access

service abnormity includes the following

contents.

6.1 Dial-up Failure6.1.1 Checking Content

Check whether users can dial up to

access to network with correct user name

and password.

6.1.2 Normal SituationIn normal situation, users can pass the

authentication.

6.1.3 Abnormal SituationUsers can not pass the authentication.

6.1.4 Abnormal Situation ProcessingIf No.678 error information appears

after user dials, this indicates that user

PC does not discover UAS device. Check

whether links in physical layer are normal.

Make sure that the links in data link layer

are connected well, and sub-interface

configuration of UAS device and VLAN

configuration on down-link switch are

correct.

If No.691 error information appears

after user dials, this indicates that user

name and password are not correct.

Check whether user dials with domain

name according to UAS requirement.

Make sure that user account has been

registered on Radius, IP pool is configured

correctly and there is an idle IP address

for distribution. Make sure that Radius

server can communicate with UAS device

normally.




processing.



6.2 On-line Failure for Users with Fixed IP Address

6.2.1 Checking ContentCheck whether users with fixed IP

addresses can get on-line normally after

they configure IP addresses manually.

6.2.2 Normal SituationUsers with fixed IP addresses can get

on-line normally after they configure IP

addresses manually.

6.2.3 Abnormal SituationUsers with fixed IP addresses can

not get on-line after they configure IP

addresses manually.

6.2.4 Abnormal Situation ProcessingIf users fail to ping to gateway address

successful ly, perform the fo l lowing

operations.

Check whether physical l inks are

normal.

Check whether configuration of ip-host

on VBUI is correct.

Check whether configuration of sub-

interface is correct.

Check whe the r VBUI i s bound

correctly.

Check VLAN configuration on down-

link device is correct.

If users can ping to gateway address

successfully, but they fail to get on-line,

perform the following operations.

Check the route information on UAS

device.

Check whether users can ping to

external network successfully with gateway

address as source address of fixed IP

address users.

Check whether DNS configuration is

correct and whether access control limit is

configured.


above operations, please contact to ZTE customer


6.3 On-line Failure for DHCP Users6.3.1 Checking Content

Check whether users can obtain IP addresses

and get on-line normally.

6.3.2 Normal SituationIn normal situation, users can obtain IP

addresses and get on-line normally.

6.3.3 Abnormal SituationUsers can obtain IP addresses, but they fail to

get on-line normally.

6.3.4 Abnormal Situation ProcessingWhen users can not ping to gateway address

successfully, check whether users bind gateway IP

address to ARP statically.

When users can ping to gateway address

successfully, perform the following operations.

Check whether WEB authent ica t ion is

configured.

Check whether the IP address use obtained is a

public network address and whether it is distributed

to up-link device through routes. If the IP address

is a private network address, check whether NAT is

configured on the up-link device.




6.4 Failing to Open Designated Web Page6.4.1 Checking Content

Check whether users can open the designated

web page after they obtain IP addresses and open

IE browser.

6.4.2 Normal SituationUsers can open the designated web page after

they obtain IP addresses and open IE browser.

6.4.3 Abnormal SituationUsers fail to open the designated web page

after they obtain IP addresses and open IE

browser.

Data Products

www.zte.com.cn

17

6.4.4 Abnormal Situation ProcessingCheck whether portal forcing configuration on

UAS device is correct.

Check whether the butt parameters and

protocol type on portal server and UAS device are

consistent.

Check whether the routes to portal server from

users are reachable.

Check whether Internet property of user PC is

set correctly.




6.5 Dial-up Failure for VPDN Users6.5.1 Checking Content

Check whether VPDN users can dial up to

access to network.

6.5.2 Normal SituationIn normal situation, VPDN users can dial up to

access to network.

6.5.3 Abnormal SituationVPDN users fail to dial up to access to network.

6.5.4 Abnormal Situation ProcessingIt is required for VPDN users to dial up with

domain name. Check whether the domain name is

contained when users dial up.

Check the configuration on local device and

make sure that VPDN domain name access is

allowed.

Check the L2TP configuration on local device

and make sure that the parameters are consistent

with that at LNS end.

Check whether UAS device can communicate

wi th LNS normal ly and whether tunnel is

established normally.

Check LNS configuration and make sure there

is enough IP address in IP pool.




6.6 Dial-up Failure for VPLS Users6.6.1 Checking Content

Check whether data packets can be

transmitted normally between VPLS and

peers.

6.6.2 Normal SituationData packets can be transmitted

normally between VPLS and peers.

6.6.3 Abnormal SituationData packets can not be transmitted

normally between VPLS and peers.

6.6.4 Abnormal Situation ProcessingCheck whether vcid, pwtype and peer

are configured correctly in VFI.

Check whether the VFI is enabled on

the interface.

Check whether LDP neighbors are

configured.

Check MAC forwarding table with

show mac-table vfi <xxx> command.

Check Layer 2 binding information with

show mpls l2transport binding command.

Check whether LDP neighbor relationship

is established correctly with show mpls ldp

neighbor command.




processing.

7 Route Abnormity ProcessingProcess ing fo r rou te abnormi ty


7.1 Invalid Static Routes7.1.1 Checking Content

Check route times with show ip route

command.

7.1.2 Normal SituationIn normal situation, static routes can

be viewed with show ip route command.

An example is shown below.



7.2.4 Abnormal Situation ProcessingCheck whether configuration is successful.

When multiple static routes with the same subnet

address and different next hop addresses are

configured, if the values of tag are the same, the

items configured later are not successful. Modify

the values of tag and configure these items again.

Check whether the metric values are the same.

If the metric values are not the same, the route

items have relationship of active and standby. Load

balancing can not be implemented in this situation.

Check whether the next hop addresses are

reachable. If they are not reachable, these static

route items are not valid and then load balancing

can not be implemented.




7.3 Establishment Failure of OSPF Neighbor Relationship

7.3.1 Checking ContentCheck OSPF neighbor state with show ip ospf

neighbor command.

7.3.2 Normal SituationIn normal situation, OSPF neighbor state is

FULL. For broadcast network and Non-Broadcast

Mult i-Access (NBMA) network, the state of

DROTHER devices can be 2-WAY.

7.3.3 Abnormal SituationOSPF neighbor is in other states.

7.3.4 Abnormal Situation ProcessingCheck whether the interface is UP.

Check whether the address of peer interface

is reachable with ping command or show arp

command.

Check whether OSPF basic parameters on

UAS device and peer device are consistent. The

parameters include Hello/dead intervals, area-ID,

authentication password and stub area flag.

Check whether MTU value is required to verify

on peer device if the peer device is not provided by

7.1.3 Abnormal SituationStatic routes are invalid, and they

can not be viewed with show ip route command.7.1.4 Abnormal Situation Processing

Check whether the next hop address is the address of peer device that connects directly. For static routes, the next hop address must be the address of peer device that connects directly. Otherwise, the static can not be valid.

Check whether the next hop address is reachable with ping command or show arp command. If the address is not reachable, the static route can not be valid, and then find out the problem on peer device or local device.

If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

7.2 Implementation Failure of Load Balancing Through Static Route

7.2.1 Checking ContentCheck static routes with show ip route

static command.7.2.2 Normal Situation

For the destination subnet to implement load balancing, there are N (the actual number depends on the number of links for load balancing) route items of different next hop addresses to the destination address. These route items have the same metric value.7.2.3 Abnormal Situation

The number N is less than that is required.

ZXUAS#show ip route

IPv4 Routing Table:

Dest Mask Gw Interface Owner pri metric

192.16.1.0 255.255.0.0 196.20.1.1 fei_1/5 static 1 0

Data Products

www.zte.com.cn

19

ZTE. If users fail to check, configure ip ospf mtu-

ignore command on butt interface of ZTE device.

Check whether the same IP address is

configured on UAS device and peer device and

whether direct-connected routes are redistributed

to both devices. In this situation, even the address

is not enabled, OSPF neighbor state can not be

FULL.




7.4 IS-IS Function Abnormity7.4.1 Checking Content

Check IS-IS adjacency relationship with show

isis adjacency [level-1 | level-2] [vrf <vrf-name>]

command.

7.4.2 Normal SituationIn normal situation, IS-IS adjacency information

is displayed. An example is shown below.

ZXUAS#show isis adjacency

Interface SystemID State Level Holds NPA Priority

fei_1/1 0000.0a0a.0a0a UP L1 9 802.2 00:e0:63:06:05:c0 64

fei_1/2 0000.0a0a.0303 UP/UP L1L2 8/8 802.2 00:e0:63:0b:44:c0 64/64

fei_1/3 0000.0a0a.0505 UP/UP L1L2 7/7 802.2 00:e0:60:0b:06:c0 64/64

check debugging information with debug

isis command. If problem is not found

according to debugging information, save

the debugging information and contact to


processing.

Note: Debugg ing cos ts sys tem

resources. It is recommended to use

debug isis command when network is idle.

Disable debugging function with no debug

all command as soon as possible after the

information is collected.

7.5 Establishment Failure of BGP Neighbor Relationship

7.5.1 Checking ContentCheck BGP neighbor relationship state

with show ip bgp neighbor command.

7.5.2 Normal SituationIn normal situation, the BGP neighbor

relationship state is Established.

7.5.3 Abnormal SituationBGP neighbor relationship state is not

Established.

7.5.4 Abnormal Situation ProcessingPing to the address of peer device to

check link connectivity.

Check BGP configuration on UAS

device and peer device, including IP

address, peer group, AS number, update-

source and authentication information. As

BGP uses TCP to establish connection

through No. 179 port, check the ACL

configuration to make sure that related

packets are not filtered by ACL.

If LOOPBACK address is used to

establish BGP neighbor relationship

on UAS device and peer device, make

sure that update-source is used as the

LOOPBACK address.

For un-direct connected devices to

establish BGP neighbor relationship, it

7.4.3 Abnormal SituationNeighbors can not be viewed with show isis

adjacency [level-1 | level-2] [vrf <vrf-name>]

command and adjacency relationship is not

established.

7.4.4 Abnormal Situation ProcessingCheck whether IS-IS configuration is correct on

devices at both ends, including area-ID, IS-IS level

and so on.

Check interface configuration and make

sure that ip router isis command is configured in

interface configuration mode.

Ping to the address of peer interface to check

link connectivity.

If no problem is found by the above operations,



is required to configure neighbor <ip-

address> ebgp-multihop command in BGP

route configuration mode. This makes

the device at a distance of multiple hops

as EBGP neighbor. Meanwhile, make

sure that users can ping to the address

of EBGP neighbor successfully from UAS

device.




processing.

7.6 Failure to Advertise BGP Aggregation Route

7.6.1 Checking ContentCheck routes that are advertised to

BGP neighbors with show ip bgp neighbor

out command.

7.6.2 Normal SituationIn normal situation, BGP aggregation

routes can be advertised.

7.6.3 Abnormal SituationBGP aggregation routes can not be

advertised.

7.6.4 Abnormal Situation ProcessingView aggregation route configuration

with aggregate-address <ip-address>

<net-mask> [count <count>] [summary-

only] [strict]. Check whether aggregation

route advertisement is configured and

what is the advertisement condition.

Pay attention to the value of parameter

<count> and check whether keyword strict

is configured.

The value of parameter <count> is the

number of aggregated subnets that must

meet the routes to be aggregated. If the

value is not 0, it is required to configure

subnets to be aggregated. The number of

subnets must not be less than the value

of parameter <count>. These subnets

must be matched in routing table. In this

ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 count 2

ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 subnet 10.1.0.0 255.255.0.0



situation, routes can be aggregated successfully. A

configuration example is shown below.

According to the above configuration, there are

three subnets of 10.0.0.0/8. They are 10.1.0.0/16,

10.2.0.0/16 and 10.3.0.0/16. When there are

two of the subnets appearing in routing table,

aggregation route 10.0.0.0/8 can be generated

successfully. Otherwise, aggregation route can not

be generated.

When the value of parameter <count> is 0, to

aggregate a route, there must be routes that are

more detailed than the aggregation route in the

routing table. Otherwise, aggregation route can not

be generated.

If keyword strict is configured, only the routes

with the same properties of MED and NEXT_HOP

can be aggregated.




7.7 Failure to Learn BGP Routes7.7.1 Checking Content

Check BGP routing table with show ip bgp route

command.

7.7.2 Normal SituationIn normal situation, UAS device can learn BGP

routes from neighbors. An example is shown below.

ZXUAS#show ip bgp routeRoutes of bgp:status codes: *valid, >best,i-internalOrigin codes: i-IGP, e-EGP, ?-incomplete Dest NextHop Metric LocPrf RtPrf Path*>i 111.1.1.2/32 2.2.2.1 0 12345678 150 200 ?*>i 111.1.1.3/32 2.2.2.1 0 12345678 150 200 ?

Data Products

www.zte.com.cn

21

7.7.3 Abnormal SituationUAS device fails to learn BGP routes from

neighbors.

7.7.4 Abnormal Situation ProcessingCheck whether BGP neighbor relationship

state is normal. If the state is normal (Established),

check BGP configuration on UAS device and peer

device. Pay attention to routing policy. Make sure

that the routes to be advertised are not filtered by

the routing policy.




7.8 Route Loop7.8.1 Checking Content

Ping to an IP address in the network.

7.8.2 Normal SituationUsers can ping to the IP address successfully.

7.8.3 Abnormal SituationSystem returns result with TTTT, indicating that

there is a route loop.

7.8.4 Abnormal Situation ProcessingRoute loop usually appears in network that

static route and default route are used. Static

route can not apperceive the change of network.

Therefore some invalid routes can not be disabled

in time. This causes route loop.

Find out the position where route loop occurs.

Check configuration on devices at both ends.

Usually, one device sends packets to up-link device

through a default route, and the up-link device

sends packets to the device through a static route.

However, the static route is wrong. Therefore,

the device does not know to which the received

packets must be send. It sends the packets to up-

link device through the default route again. This

causes the route loop. In this situation, change the

static route on up-link device to solve the problem.

If an interface configured IP address on a

device is down, the static route on up-link device

can not apperceive the change of network. The

up-link device still sends packets with

designated destination address to the

down-link device through static route.

However, the static route item does not

exist any more as the interface is down.

This causes a route loop. In this situation,

check IP address of corresponding

interface on down-link device. If the IP

address can not be used, the static route

must be deleted on up-link device.




processing.

8 Processing for Other Function Abnormity

Processing for other function abnormity


8.1 Processing for PIM-SM Function Abnormity

8.1.1 Checking ContentConfigure PIM-SM and then simulate

a terminal user at user side to receive

multicast packets.

8.1.2 Normal SituationThe user can rece ive mul t icas t

packets.

8.1.3 Abnormal SituationThe user fails to receive multicast

packets.

8.1.4 Abnormal Situation ProcessingC h e c k w h e t h e r t h e P I M - S M

configuration is correct.

Check Layer 2 multicast forwarding

information with show ip igmp snooping

command.

Check multicast routing table with

show ip mroute command.

Check multicast routing table of single

multicast group with show ip mforwarding



group-address <ip-address> command.

Check interact ion information of

PIM-SM protocol with debug ip pimsm

command.

C h e c k w h e t h e r u s e r c i r c u i t i s

enabled with ip pim sm command, and

check whether multicast properties are

associated with user template.

Check whether IGMP interaction is

normal between user and the device by

capturing packets at user side.




processing.

8.2 Maintaining MPLS L3VPN8.2.1 Checking Content

Check MPLS VPN information with the

following commands.

show ip rout vpnshow ip rout vrf <vrf>show ip protocol routing vrf <vrf>show ip bgp neighbor

8.2.2 Normal SituationVPN routes from peer PE can be

viewed with show ip route vpn. An example

is shown below.

PE1# show ip rout vpnRoutes of vpn:Dest NextHop Type ASN Addr Peer3.3.3.3/32 10.1.1.2 0 100 1 0.0.0.010.1.1.0/30 10.1.1.1 0 100 1 0.0.0.010.1.1.1/32 10.1.1.1 0 100 1 0.0.0.04.4.4.4/32 172.10.1.2 0 100 1 172.10.1.211.1.1.0/30 172.10.1.2 0 100 1 172.10.1.211.1.1.1/32 172.10.1.2 0 100 1 172.10.1.2

PE1#show ip rout vrf vpn1IPv4 Routing Table:Dest Mask Gw Interface Owner pri metric3.3.3.3 255.255.255.255 10.1.1.2 fei_1/1 static 1 04.4.4.4 255.255.255.255 172.10.1.2 fei_1/2 bgp 20 010.1.1.0 255.255.255.252 10.1.1.1 fei_1/1 direct 0 010.1.1.1 255.255.255.255 10.1.1.1 fei_1/1 address 0 011.1.1.0 255.255.255.252 172.10.1.2 fei_1/2 bgp 20 011.1.1.1 255.255.255.255 172.10.1.2 fei_1/2 bgp 20 0

VRF routing table can be viewed with show ip route vrf <vrf> command. An example is shown below.

VPN routes can be imported in VRF routing table.

Check whether VPN labels are distributed normally with show ip protocol routing vrf <vrf> command. An example is shown below.

PE1#show ip protocol routing vrf vpn1Routes of vpn:status codes: *valid, >best, s-stale

Dest NextHop Intag Outtag RtPrf Protocol*> 3.3.3.3/32 10.1.1.2 20 notag 1 static*> 4.4.4.4/32 172.10.1.2 18 19 20 bgp-ext*> 10.1.1.0/30 10.1.1.1 17 notag 0 connected*> 10.1.1.1/32 10.1.1.1 16 notag 0 connected*> 11.1.1.0/30 172.10.1.2 19 17 20 bgp-ext*> 11.1.1.1/32 172.10.1.2 21 16 20 bgp-ext

In the result of show ip bgp neighbor command,

neighbor relationship state is Established.

8.2.3 Abnormal SituationVPN is not through and VRF routing table is

wrong.

8.2.4 Abnormal Situation ProcessingCheck configuration of MPLS VPN on both PE

devices. Make sure that MPBGP is configured,

VRF routes are advertised to the peer PE, and

VRF routes are not filtered by routing policy.

If VPN routes exist but they are not imported

to VRF routing table correctly, check the policy of

RT. If RT policies at both ends do not match, VPN

routes can not be imported to VRF routing table

correctly.

Data Products

www.zte.com.cn

23

If BGP neighbor relationship state is not correct,

refer to corresponding connects of processing for

BGP neighbor.

If public network labels are not distributed

normally, check whether the fol lowing LDP

configuration is configured.

Enable MPLS with mpls ip command in global

configuration mode. By default, the signaling

protocol is LDP. Only when MPLS is enabled

globally can mpls ip command be valid on an

interface.

Configure mpls ldp router-id loopback1 force.

This forces loopback1 to be the router-id in

LDP.

Configure mpls ldp access-fec host-route-only.

This means that labels are only distributed to

host address.




8.3 Invalid ACL Configuration8.3.1 Checking Content

Check ACL configuration.

8.3.2 Normal SituationACL configuration is valid.

8.3.3 Abnormal SituationACL configuration is invalid.

8.3.4 Abnormal Situation ProcessingCheck whether ACL configuration is bound to

interface with show ip access-list bound command.

Before the ACL configuration is bound to an

interface, the configuration is not valid.

Check whether ACL rules are configured

correctly with show acl command. Check whether

the matching field and action are correct. Check

whether the order of rules meets the requirements

of users.

Dynamic modification of ACL rules will make

the ACL configuration invalid. In this situation,

disable the application of ACL configuration on the

interface and configure the new ACL rules, and

then apply the configuration to interface

again.




processing.

8.4 Application Failure of ACL Configuration to Interface

8.4.1 Checking ContentC o n f i g u r e A C L a n d a p p l y t h e

configuration to an interface.

8.4.2 Normal SituationACL configuration can be applied to

the interface and the configuration is valid.

8.4.3 Abnormal SituationSystem prompts error information

when ACL configuration is applied to an

interface.

8.4.4 Abnormal Situation ProcessingCheck whether other ACL configuration

has been applied to this interface. Only

one ACL configuration can be applied to

an interface. If the later ACL configuration

i s ind ispensable for the in ter face,

try to combine the rules of two ACL

configurations.

If this problem still exists after the



processing.

8.5 Failure to Obtain Device Information through SNMP

8.5.1 Checking ContentCheck SNMP configuration information

with show snmp config command.

8.5.2 Normal SituationThere is configuration of a community

with ro or rw privilege, containing AllView,

for example, snmp-server community

<community-name> view AllView ro.



8.5.3 Abnormal SituationThere i s no con f i gu ra t i on o f a

community or there is community without

AllView.

8.5.4 Abnormal Situation ProcessingConfigure a community with AllView,

and make the community read information.




processing.

8.6 Configuration Failure of Device through SNMP

8.6.1 Checking ContentCheck SNMP configuration information

with show snmp config command.

8.6.2 Normal SituationThere is configuration of a community with rw

privilege, containing AllView, for example, snmp-

server community <community-name> view

AllView rw.

8.6.3 Abnormal SituationThere is no configuration of a community with

rw privilege or there is community without AllView.

8.6.4 Abnormal Situation ProcessingConfigure an rw community with AllView, and

make the community write information on NMS.



support center for further processing. ■

www.zte.com.cn

Data Products 25

1 Network TopologySVLAN is configured on T64G. T64G connects

to UAS 10600 through dual up-links. The two interfaces on T64G are gei_4/1 and gei_5/1. T16C-1 and T16C-2 connect to T64G. The network topology is shown in Figure .

that services were not normal. When users pinged to the gateway address of UAS 10600 on PC, most of the packets were lost and only few packets reached gateway. The result was the same when engineers pinged to the gateway address of UAS 10600 on PC in machine room of service operator. Network management of T16C-1 and T16C-2 that transmit transparently to UAS 10600 through T64G were normal. That is, engineers could ping to gateway address on UAS 10600 successfully and on packet was lost.

3 Malfunction AnalysisI n the ne twork topo logy, T64G

connected UAS 10600 through dual up-links. As few packets could reach gateway and network management of T16C-1 and T16C-2 that transmit transparently to UAS 10600 through T64G were normal (that is, engineers could ping to gateway address on UAS 10600 successfully and on packet was lost), engineers considered that the links from T16C-1 and T16C-2 to UAS 10600 were through, and the network VLAN was normal. This indicated that the problem may be in the configuration of QinQ.

Engineers checked whether there was the same VLAN conf igura t ion on interfaces of UAS 10600 (that is, gei_2/1 and gei_1/1) that connected to T64G. It was found that there was no

Figure 1. Network Topology

⊙ Wang Yufeng / ZTE Corporation

Key words: SVLAN, UAS, QinQ, double layer labels, users of fixed IP addresses

It is required to modify the data of special line user of Internet bar that connects to T16C-1 and T16C-2. Users are shifted to gei_5/1 from gei_4/1 on T64G. Therefore, data on T16C-1, T16C-2, gei_4/1 and gei_5/1 of T64G will be modified. Meanwhile, data on gei_2/1 of UAS 10600 will be shifted to gei_1/1.

2 Malfunction SituationConfigurations on devices were changed

correctly. However, users in Internet bar said





such configuration. Meanwhile, both gei_2/1 and gei_1/1 were configured with outer layer label vlan5 and the inner layer labels were different. This indicated that the problem was not on UAS 10600. As both gei_2/1 and gei_1/1 were configured with outer layer label vlan5, the interfaces of T64G (that is, gei_4/1 and gei_5/1) that connected to UAS 10600 must also be configured with outer layer label vlan5.

Engineers continued to check interface configurations of T64G. TAGs of gei_4/1 and gei_5/1 were configured correctly. However, outer layer labels were configured to native vlan on the interfaces of T64G (that is, gei_4/2 and gei_4/5) that connected to T16C-1 and T16C-2. Related interface configuration on T64G is shown below.

interface gei_4/2description to-lichuanT16C-1switchport hybrid native vlan 5switchport hybrid vlan 5 untagswitchport qinq customer

interface gei_4/5description to-lichuanT16C-2switchport hybrid native vlan 5switchport hybrid vlan 5 untagswitchport qinq customer

interface fei_2/1description to_lichuan2403_1switchport hybrid native vlan 1switchport hybrid vlan 5 untagswitchport hybrid vlan 4094 untagswitchport qinq customer /*vlan 5 configured on this interface is for the old service.*/

Engineers checked configuration of vlan qinq session-node. They found that there was no configuration for data form gei_4/2 and gei_4/5 to gei_5/1 on T64G. This caused the problem.

As outer layer label vlan5 was configured on gei_4/1 and gei_5/1 of T64G, data packets form T16C-1 and T16C-2 were sent to these two interfaces. In MAC table of T64G, gei_4/1 had learnt the MAC addresses of T16C-1 and T16C-2. Therefore, data packets from form T16C-1 and T16C-2 were sent to gei_4/1 directly. There were only few broadcast packets received on gei_5/1 of T64G. Then T64G sent these packets to UAS 10600. This was why that few packets could reach gateway when users in Internet bar pinged to gateway address of UAS 10600. In normal situation, if switchport hybrid native vlan 5 was configured

on gei_4/2 and gei_4/5, it was not necessary to configure vlan qinq session-no. However, outer layer label vlan5 was configured on the interfaces of dual up-links on T64G, vlan qinq session-no must be configured on T64G. This made that the data packets from gei_4/2 and gei_4/5 were sent to gei_5/1.

4 SolutionEngineers modified the configuration of gei_4/5

and gei_4/2 on T64G, as shown below.

interface gei_4/2description to-lichuanT16C-1switchport hybrid native vlan 107switchport hybrid vlan 5 untagswitchport hybrid vlan 4094 untagswitchport qinq customer

interface gei_4/5description to-lichuanT16C-2switchport hybrid native vlan 5switchport hybrid vlan 5 untagswitchport hybrid vlan 4094 untagswitchport qinq customer

Besides, two vlan qinq session-no commands were added to the configuration, as shown below.

vlan qinq session-no 43 customer-port gei_4/2 uplink-port gei_5/1 in-vlan 324-448 ovlan 5vlan qinq session-no 44 customer-port gei_4/5 uplink-port gei_5/1 in-vlan 324-448 ovlan 5

After modification, engineers tested the network services. The services were normal. The problem was solved.

5 Experience SummaryWhen a switch connects to a UAS device

t h rough dua l up - l i n ks , do no t con f i gu re superimposed VLAN no matter if there is single layer label or double layers of labels. For users of dial-up service, No.678 error information will appear when users dial up. For users with fixed IP addresses, they can not get on-line normally. ■

www.zte.com.cn

Data Products 27

1 Network TopologyAs shown in Figure 1, multiple dial-up user

domains are configured on BAS device. In different

domains, users are required to obtain IP addresses

in designated IP address pools. Therefore, in

subscriber-template configuration of domain,

user addresses are bound to IP address pools of

designated VBUIs.

designated IP address pools. Therefore, in subscriber-template

configuration of domain, user addresses are bound to IP address

pools of designated VBUIs.

An example is shown below.

Domain 1 is a DIAL domain. Users in this domain must obtain

IP addresses from address pool of VBUI1.

Domain 2 is a CNC domain. Users in this domain must obtain

IP addresses from address pool of VBUI2.

Domain 3 is an IPTV domain. Users in this domain must

obtain IP addresses from address pool of VBUI3.

Configuration of VBUI1 is shown below.

interface vbui1

ip address 115.56.144.1 255.255.252.0

ip address 219.154.98.1 255.255.254.0 secondary




description for_PPPOE_dial

ip pool 1 pppoe_pool1 115.56.144.2 115.56.147.254






interface vbui2 ip address 10.254.64.1 255.255.255.0description for_helpip pool 21 help_pool1 10.254.64.2 10.254.64.254


⊙ Liu Peng / ZTE Corporation

Key words: IP address pool, BAS, VBUI, user domain

2 Malfunction SituationThere are multiple dial-up user domains

configured on BAS device. In different domains,

users are required to obtain IP addresses in

IP Address Pool ConfigurationIP Address Pool Configuration


IP Address Pool ConfigurationFebruary 2009 Issue 153


interface vbui3

ip address 10.169.72.1 255.255.254.0

description for_IPTV

ip pool 31 iptv_pool1 10.169.72.2 10.169.73.254

Configuration of domain 1 is shown below.

domain 1

alias dial

subscriber-template

ip address interface vbui1


domain 2

alias cnc

subscriber-template



domain 3

alias iptv

subscriber-template


The above configurations meet the

requirement that users in different domains

will obtain IP addresses in designated IP

address pools.

However, when IP address pools of

VBUI1 are not enough and it is necessary

to add new address pools, a problem

will appear. For current version, a VBUI

interface supports up to 5 IP addresses.

One of the addresses is the primary

address, and the others are secondary

addresses. The five addresses are the

gateway addresses of corresponding

address pools. In fact, the offices are

not able to provide a large segment of

continuous addresses. Usually they

provide small segment of discontinuous addresses

of C type. When engineers can not define IP

addresses of a VBUI, they can decrease the length

of subnet mask to provide more addresses in the

address pools of this VBUI.

The worst situation is that the office provides

5 discontinuous addresses of C type. Therefore,

there are up to 5 address pools of C type in

the VBUI. This obviously can not meet the fact

demand. To add new address pools, engineers

have to added new VBUI interface and then add

the new address pools. However, subscriber-

template of domain 1 is bound to VBUI1, users in

domain 1 still can not obtain the new addresses in

the new VBUI interface.

3 SolutionIn domain 1, there are a lot of dial-up service

users. If the domain is only bound to a fixed VBUI

interface, the IP addresses in the address pools of

this VBUI are not enough for the users. Therefore,

modify the configuration of domain 1, as shown

below.

domain 1

alias dial

subscriber-template

ip address interface vrf /*users can obtain IP

address from all available VBUI interfaces*/

However, after configuration of domain 1 is

modified, another problem will appear. That is,

users in domain 1 can obtain IP addresses from

all available VBUI interfaces, but address pools of

VBUI2 and VBUI3 are not designated. As a result,

users in domain 1 can also obtain IP addresses in

address pools of VBUI2 and VBUI3. To solve the

problem, modify the configuration of VBUI2 and

VBUI3.


www.zte.com.cn

Data Products 29

interface vbui2

ip address 10.254.64.1 255.255.255.0

description for_help

i p p o o l 2 1 h e l p _ p o o l 1 1 0 . 2 5 4 . 6 4 . 2

10.254.64.254 domain 2


interface vbui3

ip address 10.169.72.1 255.255.254.0

description for_IPTV

i p p o o l 3 1 i p t v _ p o o l 1 1 0 . 1 6 9 . 7 2 . 2

10.169.73.254 domain 3

Meanwhile, add a new VBUI interface, VBUI4.


interface vbui4 ip address 61.53.106.1 255.255.255.0 ip address 61.53.107.1 255.255.255.128 secondary description for_PPPOE_dial-1 i p p o o l 6 p p p o e _ p o o l 6 6 1 . 5 3 . 1 0 6 . 2 61.53.106.254 domain 1 i p p o o l 7 p p p o e _ p o o l 7 6 1 . 5 3 . 1 0 7 . 2 61.53.107.126 domain 1

4 Experience SummaryFor ZXUAS 10600 and ZXUAS 10800E of

V2.8.01.B.26 and V2.8.01.B.26.P01, there are

up to 5 IP addresses in a VBUI interface. Use

continuous network segment and get more

addresses by decreasing the length of subnet

mask. This decreases the number of advertised

route items, and enlarges the capacity of address

pool in VBUI.

In an IP address pool of VBUI, there are up to

4 IP addresses of C type. If in the segment there

are more that 4 IP addresses of C type, hold the

addresses by define multiple IP address

pools.

When users configure address pools

of a VBUI interface, it is recommended to

associate these pools to corresponding

domains no matter whether it is necessary.

When there are multiple domains for dial-

up service users and users in a domain

want to obtain addresses form different

VBUI interfaces, i t is impossible to

associate the users in this domain with

multiple VBUI interfaces at the same

time. It is only possible to set the address

obtainment of subscriber-template in the

domain to ip address interface vrf. If an

address pool of a VBUI interface is not

associated with any detailed domain,

the address pool can be distributed to all

users. That is, users in a domain of which

the address obtainment of subscriber-

template is set to ip address interface vrf

can obtain IP addresses from any VBUI

interface with such configuration. To

modify the configuration of address pool

in a VBUI interface, it is required to delete

the old address pools. This will make all

users who have obtained IP addresses

off-line. Therefore, it is recommended to

associate these pools to corresponding

domains at the very beginning.

Generally, common dial-up service

users use a lot of address pools. Users of

other services use a few address pools.

Therefore, it is recommended to set the

address obtainment of subscriber-template

in a common dial-up service user domain

to ip address interface vrf, and set the

address obtainment of subscriber-template

in other dial-up service user domain to ip

address interface interface vbuiX. ■



1 Network TopologyIt is required to configure link aggregation in

VLAN 100 between 2500S and 2826S, as shown

in Figure 1.

2 Configuration ProcessConfiguration of 2500S is shown below.

UAS#set vlan 100 createUAS#show trunkingTrunkingAgList:---------------1UAS#show vlan 100VlanVersionNumber:1 MaxVlanId:4094MaxSupportedVlans:4094 NumVlans:5----------------------------VlanId : 100VlanStaticName :StaticEgressPorts :(slot-1) 1(slot-2) 1 2ForbiddenEgressPorts:UntaggedPorts

The following points are to be considered.

1. Add the ports to VLAN 100, as shown below.

UAS#set vlan 100 slot 2 port 1 op 1UAS#set vlan 100 slot 2 port 2 op 1UAS#no set vlan 1000 slot 2 port 1 op 1/*delete vlan 1000 on slot 2 port 1/


Link Aggregation Configuration on UAS2500SLink Aggregation Configuration on UAS2500S⊙ Li Yong / ZTE Corporation

Key words: 2500S, 2826S, link aggregation, LACP

www.zte.com.cn

Data Products 31

The ports can be added to the VLAN in batch,

as shown below.

UAS#set vlan 101-201 slot 2 port 1 op 1

UAS#set trunking slot 2 port 1 agport 1


2. When a new VLAN is to be added after

aggregation, the ports can not be added to VLANs

respectively, and VLANs can not be added in

batch. Use the following command, as shown in

the table given below.

UAS#set vlan 300 slot 2 port 1-2 op 1

3. Delete a port from the aggregation group,

as shown below.


/*the aggregation group number is 0*/

4. If UAS2500S is reset, the configuration of

aggregation will be lost. No.678 error information

will appear when users dial up. Therefore, the

following commands must be configured after

reset.



Configuration of 2826S is shown below.

zte(cfg)#show runSoftware version: 1.1Switch's Mac Address: 00.d0.d0.fc.76.f1!syslocation No.68_Zijinghua_Road,Yuhuatai_District,Nanjing,CHINAcreate user adminloginpass B612AD6F2259089A79740AD7CB5A38BFline-vty timeout 10!!set port 2 pvid 100!set vlan 1 add port 1-24 untag

set vlan 1 add trunk 1-8 untagset vlan 100 enableset vlan 100 add port 2 untagset vlan 100 add port 1,12 tagset vlan 100 add trunk 1 tag!!!set lacp enableset lacp aggregator 1 add port 1,12set lacp aggregator 1 mode static!!create community public publiccreate view zteView include 1.3.6.1set community public view zteView!

LACP mus t be se t to s ta t i c on

2826S. Otherwise, informat ion that

remote computer does not respond. The

configuration is shown below.

zte(cfg)#set lacp aggregator 1 mode

static

zte(cfg)#show lacp

Lacp is enabled.

Lacp priority is 32768

PortNum GroupNum GroupMode LacpTime

LacpActive

----------- ----------- ----------- -----------

--------

1 1 Static Long

True

12 1 Static Long

True

After the configuration, users can pass

authentication and obtain IP addresses

in address pools. After users get on-

line normally, if one of the links in the

aggregation group is down, a packet will

be lost when engineers implement ping

test on PC. When the link recovers, no

packet is lost. ■



1 Network TopologyZXUAS 10600 is in aggregation layer

of MAN. It connects HW DSLAM on

down-link, and two HW NE80 devices are

connected on up-links. IS-IS is enabled.

The network topology is shown in Figure 1.

2 Malfunction SituationIS-IS configuration of ZXUAS 10600 is shown

below.

router isis area 49.0898 system-id 2180.7714.8032 is-type level-2-only

interface loopback1 ip router isis isis circuit-type level-2-only ip address 218.77.148.32 255.255.255.255

interface gei_1/1 ipaddress 218.77.150.138 255.255.255.252 ip router isis isis circuit-type level-2-only

Users could view IS-IS neighbors with show isis

adjacency command, but they failed to view routes

learnt by IS-IS-l2 with show ip route command. This

indicates that IS-IS did not run effectively between

ZXUAS 10600 and HW NE80 devices.


Processing of IS-IS Malfunction on ZXUAS 10600Processing of IS-IS Malfunction on ZXUAS 10600⊙ Wang Yufeng / ZTE Corporation

Key words: UAS, IS-IS, metric-style, narrow, wide

www.zte.com.cn

Data Products 33

3 Malfunction AnalysisEngineers could not view the configurations on

HW NE80 devices. They only viewed isis circuit-

type level-2-only type with show isis adjacency

command. Engineers modified the value of

parameter isis ignore-mtu. This modification was

necessary. That is because the MTU on HW

devices is more than 1500, and MTU on ZTE

devices is 1500. This modification ensures that

the data on device at both ends could match

and no packets would be lost. However, after the

modification, the problem still existed.

Engineers also modified the value of parameter

priorit, changed the type isis circuit-type level-2-

only to isis circuit-type level-1-2, and redistributed

direct-connected routes. But the problem still

existed.

4 SolutionWith the help of office staff, engineers obtained

related configuration on HW NE80 devices, as

shown below.

isis 1 is-level level-2 cost-style wide network-entity 49.0898.2180.7714.8002.00 filter-policy 2003 import default-route-advertise preference 115

interface GisgabitEthernet9/0/4 i p a d d r e s s 2 1 8 . 7 7 . 1 5 0 . 1 3 7 255.255.255.252 isis enable 1 isis circuit-level level-2 isis cost 150 mpls mpls ldp traffic-policy anti_virus inbound

The above information showed that the

type of cost-style on HW NE80 was wide.

Therefore, engineers modified the type of

metric-style on ZXUAS 10600 to wide and

then IS-IS ran normally between ZXUAS

10600 and HW NE80 devices.

5 Experience SummaryBy default, the value of parameter

metric-style on ZXUAS 10600 is narrow,

and that on HW NE 80 is wide. For ISIS

configuration, the values of parameters on

devices at both ends must be consistent. ■



1 MPLS VPN OverviewVPN provides a private communication

environment for users to transmit private

data information with public network

resources. The private data information is

invisible to users outside the VPN network.

There are multiple technologies to create

VPN, such as data encryption, tunnel

and so on. Among these technologies,

MPLS VPN is widely used due to its

good flexibility, security and expansibility.

Internet service providers begin to operate

inter-AS MPLS VPN services as intra-

AS MPLS VPN services have developed

maturely.

MPLS MP-BGP VPN Configuration⊙ Zhu Yanbo / China Unicom

Figure 1. MPLS L3VPN Packet

Key words: MPLS, BGP, VPN

MPLS can use multiple types of link layer

protocols to provide connection-oriented services

for network layer. MPLS is a label switching

technology which was developed to improve the

forwarding speed on routers. However, it is widely

used in VPN field.

Devices in MPLS network are divided into

access layer device and core layer device. Access

layer device is called PE, working as the MPLS

network gateway of user network access. PE adds

MPLS packet header to messages when messages

enter MPLS network and removes MPLS packet

header when messages leave MPLS network.

Figure 1 shows a MPLS L3VPN packet that is

captured in IP network.

www.zte.com.cn

Data Products 35

In t he packe t heade r, MPLS add ress

information is contained for forwarding. The

address is the label information shown in Figure

. Users can know how to process MPLS packets

according to Label Forwarding Information Base

(LFIB).

A message can be encapsulated with MPLS

header for multiple times. In theory, the number

of encapsulation layers is only limited by the

maximum length of packet that a device can

support. According to information shown in Figure

, the message is encapsulated with two MPLS

headers. The headers are between IP data

message of VPN user and Ethernet message

header.

When the packet leaves the entrance PE

device, it reaches a core device (P) of MPLS

network. P device only implements operations on

the packet according to outer layer encapsulation

information, and it does not care other information.

This shows transparency of MPLS to information.

Af ter MPLS encapsu la t ion, the packet

goes through core P devices and then reaches

egress PE device. In fact, this is the transparent

transmission course of a message with label in

LSP. The contents in the message are not changed

and the contents are not visible to devices outside

the LSP tunnel. The user devices in MPLS network

are called CE devices. CE connects with PE

directly.

There are multiple label distribution protocols,

such as LDP, RSVP and BGP. The label format

on each Label Switching Router (LSR) is the

same. No mater what label distribution policy is

used in the label distribution protocol, each LSR

generates a unique LFIB to provide basis for MPLS

packet forwarding. Establishment of LSP tunnel is

related to routing table information. When routes

are changed, LSP is also changed. When there

are multiple routes to the same destination, load

balancing may also be implemented through LSP.

LSP is a unidirectional tunnel. That is, the

physical route of the LSP from PE-A to

PE-B may be absolutely different with

that of the LSP from PE-B to PE-A.

The two LSP tunnels are used for data

transmission in two directions.

To meet the requirement of MPLS

application in VPN, common BGP protocol

is extended (refer to RFC2283). It is called

Multi-protocol Extensions for BGP-4 (MP-

BGP). MP-BGP succeeds the attributes

of common BGP, and some new concepts

are also introduced to MP-BGP, such as

Route-Distinguisher (RD) and Router

Target (RT).

RD is introduced to solve the problem

of VNP address superposition. MPLS VPN

extends the IPv4 address with RD and

generates VPNv4 address family.

I f the same RD is distr ibuted to

different MPLS VPNs, what will happen? In

fact, if the IP addresses of these VPNs do

not overlap, it does not matter. However, if

the IP addresses of these VPNs overlap,

serious problem will occur. Generally, MP-

BGP does not enable load balancing on

multiple links. If RDs and IPv4 addresses

o f two VPN are the same, VPNv4

considers that they are the same address

and the better route will be used. This will

cause serious problems in network where

MP-BGP Route Reflector (RR) router is

used.

RT is a special attr ibute of BGP

Community. It is used to introduce VPN

instance. The application of RT makes

MPLS VPN network more f lex ib le .

Users can set RT according to their

requirements. It is RT Rewrite technology.

Part information of a MP-BGP update

message which is captured in a network is

shown in Figure 2.

Besides RT and RD information, there


MPLS MP-BGP VPN ConfigurationFebruary 2009 Issue 153

is BGP information in Figure 2. Next-Hop attribute

is described below.

In application of common BGP, Next-Hop

attribute is the basis to generate a routing table.

In MPLS VPN, it is used to select LSP tunnel. In

Figure , for the message to 20.0.0.0/24, PE adds a

MPLS packet header to it with label 22 and selects

a LSP tunnel according to the net hop address

4.4.4.4. When BGP advertises route information,

if the next hop address is changed, it is required

to distribute a new label. This is very important for

inter-AS MPLS VPN services. It is to ensure the

traceability and consistency of information. In fact,

loopback address of a device is usually used as

the Next-Hop of BGP routes.

What will happen if loopback addresses of some

devices in MPLS network are aggregated and only

the aggregation route is advertised? As shown in

Figure 3, R2 aggregates the loopback addresses of

R3, R4 and R5 and sends the aggregation route to

R1. When there is a packet to 10.0.0.3 on R1, will

R1 add a label 10 to 10.0.0.0/24 to the packet and

send it to R2? Of course, R1 will not.

As a PE device, R2 implement operation on a

packet according to the information in outer layer

of MPLS packet header, especially when there are

multiple layers of MPLS encapsulation. When R2

receives a packet with label 10, it does not know

whether the packet is to 10.0.0.3 or 10.0.0.4. R2

feels confused and the packet is lost. This is a

problem that must be solved in inter-AS MPLS

VPN services. In intra-AS MPLS VPN networks,

it is easy to avoid loopback address aggregation.

However, in inter-AS MPLS VPN networks, usually

routes are aggregated.

2 Intra-AS MPLS VPNFigure 4 shows the topology of an intra-AS

MPLS VPN network.

Figure 3. Next-Hop Address Aggregation

Figure 2. Part Information of a MP-BGP Update Message

Figure 4. Intra-AS MPLS VPN Network Topology

www.zte.com.cn

Data Products 37

PE-A and PE-B run MP-BGP and create

VPNV4 IBGP neighbor relationship. They distribute

labels for VPN routes and advertise the results to

each other. Both devices use their own loopback

address as the Next-Hop address. LDP is used to

distribute labels for public routes. A nonstop tunnel

based on loopback address is established between

PE-A and PE-B.

When a user 1.1.1.1 in VPN-1 on PE-A sends a

message to user 2.2.2.2, PE-A searches for route

related to VPN-1. The route information is shown

below.

This information is provided by PE-B through

MP-BGP. PE-B tells its MP-BGP peer that the

messages to 2.2.2.2 in VPN-1 must be added

MPLS packet header with label X before the

messages are sent to PE-B. Therefore, PE-A

adds a MPLS packet header with label X to the

message. Then PE-A searches for information in

its LFIB and finds out the following information.

According to the above information, PE-A adds

a header with label Y to the message and sends

the message from interface INTF-A. The message

to user 2.2.2.2 is encapsulated with two layers

of MPLS headers and it is send to PE-B from

interface INTF-A on PE-A. When PE-B receives

the packet, it searches for information in its LFIB

according to the inner layer label X. It knows that

the packet is to user 2.2.2.2 in VPN-1 on PE-B.

Therefore, PE-B removes the MPLS header and

sends the message to user 2.2.2.2.

PE devices judge which VPN the received

message belongs to according to inner layer label

of the packet. That is, inner layer label is used to

isolate VPN tunnels established between the same

PE devices. For the same VPN instance on the

same PE, labels distributed for different

routes are different. As MP-BGP neighbor

relationship is established between PE

devices directly, only PE devices know

VPN routes and the labels distributed for

these routes. A P device does not know

how to process a packet only with an inner

layer label. With the outer layer label,

the packet encapsulated with inner layer

label can be sent to destination PE from

entrance PE through the nonstop tunnel.

This ensures that the messages can be

transmitted correctly.

3 Inter-AS MPLS VPNThere are three types of topologies of

inter-AS MPLS VPN network:

OPTION-A

OPTION-B

OPTION-C

OPTION-A is also called VRF-TO-

VRF. In two adjacent ASs, ASBR in each

AS is configured with VPN instance, and it

considers the VPN instance on peer ASBR

as CE device. VPN instance routes on

peer PE device are redistributed to local

PE device by local ASBR. Next-Hop is

also the local ASBR. IP messages of users

are re-encapsulated with MPLS packet

headers by local ASBR before they are

transmitted. In the sight of PE device, local

ASBR is the destination PE router that

connects to peer VPN users.

As shown in Figure 5, VPN tunnel is

broken between two ASBRs. User data

is transmitted in primary message form

between ASBRs without MPLS header

encapsulation. VPN networks are isolated

by VPN instances on ASBRs. The result

shows that user private data is exposed to

other devices between PE devices.

For OPTION-A, to ensure VPN

Address Next-Hop Label

VPN-1: 2.2.2.2 PE-B X


PE-B INTF-A Y



W h e n A S B R l e a r n s V P N r o u t e

information from peer ASBR, it advertises

the information to IBGP neighbors in AS.

The neighbors can be RR. At last, PE

device learns the information.

B e f o r e a d v e r t i s i n g V P N r o u t e

information to IBGP neighbors, ASBR

determines whether to change next hop

address or not. If next hop address is

changed, new labels will be distributed.

In the sight of PE device, since Next-

Hop is the local ASBR, data is transmitted

through LSP between PE and ASBR. For

further data forwarding, it is implemented

by ASBRs in the two ASs.

If next hop address is not changed, the

next hop address of VPN route that PE

receives is the interface address of ASBR

in peer AS that connects local ASBR. Such

route will not be broadcasted

in local AS and therefore

there is no corresponding

LSP. When devices of some

v e n d o r s w o r k a s A S B R

devices in OPTION-B, local

ASBR generates an address

in local routing table for inter-

connect ion wi th the peer

ASBR automatically. That is a

32-bit host route of Next-hop.

This route can be broadcasted

to IGP routing table in local

AS, and then labels will be

distributed and a LSP will be

established. The 32-bit host

route can also be broadcasted

to PE device through BGP.

However, this adds another

layer of encapsulation label to

the VPN packets besides the

MPLS packet encapsulation

label, which makes processing

isolation, it is required for each VPN instance to

establish independent inter-connected physical

links or logical links. If connections between

ASBRs use POS interfaces, there will be great

difficulty. However, as device requirements are low

and routers that support intra-AS MPLS VPN can

be used, as well as it is not necessary to extend

protocols, OPTION-A still has its advantages when

there are not many VPN networks.

In OPTION-B, MP-BGP VPNv4 EBGP neighbor

relationship is established between ASBRs. VPN

routes and related label information are advertised

between ASs.

To establish EBGP neighbor relationship, direct-

connected interfaces on ASBRs are used as the

Next-hops, as shown in Figure 6. Although VPN

tunnel is broken between two ASBRs, inner layer

tunnel between VPN instances is still normal.

www.zte.com.cn

Data Products 39

of packet on ASBR more complicated. It is important to change

the next hop address. That is why devices of some vendors

change the next hop address to itself by default.

In OPTION-B, ASBR must process a lot of VPN route

information. Therefore, devices used in OPTION-B are with high

requirements. In application of OPTION-B, if RD filtration function

is disabled on all devices, a lot of useless VPN route information

will be transmitted between ASs, which costs network resources.

It is recommended to use policy to limit route transmission.

Another method is to create required VPN instances on ASBR

without binding VPN instances to interfaces.

OPTION-C is the most complicated. It can establish nonstop

tunnel between PE devices in different ASs.

In OPTION-C, PE devices obtain VPN route information by

establishing MP-BGP VPNv4 EBGP neighbor relationship or by

creating RR in ASs.

In OPTION-C, VPN route information is transmitted between

PE devices directly or forwarded by RR. The next hop address

of the received VPN route is the primary promulgator, that is, the

loopback address of peer PE device. The address can not be

changed. In the sight of PE device, there must be a LSR to peer

PE device. Network topology of OPTION-C is shown in Figure 7.

Figure 7. OPTION-C Network Topology

Therefore, it is necessary to extend BGP to

make ASBR distribute MPLS label to Next-hop

address of local PE and advertise it to peer ASBR.

ASBR not only establishes MP-BGP neighbor

relationship PE device or RR in local AS, but also

establishes IBGP neighbor relationship. Therefore,

ASBR can broadcast route information and label

information learnt peer ASBR neighbors to local

PE device and RR. As a result, PE, ASBR and

RR have the Next-hop of VPN route, that is, the

loopback address of peer PE device.

To transmit data to peer PE device between

PE device and ASBR in local AS correctly, it is only

necessary to establish a nonstop tunnel between

PE device and ASBR in local A, that is, the MPLS

outer layer tunnel, as shown in Figure 7.

In Figure 7, when device 1.1.1.1 in VPN-1

wants to send a message to device 2.2.2.2, PE-A

implements the following steps.

1. PE-A finds the following information.

This information is learnt by establishing

MEBGP neighbor relationship between PE devices.

It is necessary to know how to reach the next hop

PE-B.

2. PE-A searches for forwarding information

to PE-B, as shown below.

3. PE-A searches for forwarding information

of ASBR in AS-A (next hop of PE-B), as shown

below.

At last, the message to device 2.2.2.2 is

encapsulated with three layers of labels (from

inside out, they are X, Y and Z) and transmitted

The establishment of LSP tunnel between ASBRs in AS-A and

AS-B is the application of intra-AS. It is easy to establish the LSP.

The key point is to establish a tunnel about PE-B between PE-A

and ASBR in AS-B and then connect the tunnel to the established

LSP in AS-B. The tunnel between PE-A and ASBR in AS-B can

be divided into two tunnels. One is an intra-AS tunnel between

PE-A and ASBR in AS-A, the other is an inter-AS tunnel between

ASBR in AS-A and ASBR in AS-B.


VPN-1: 2.2.2.2 PE-B X


PE-B AS-A ASBR Y


AS-A ASBR INTF-A Z



from interface INTF-A.

In OPTION-C, when there is RR in each AS,

if the next hop of VPN route is changed to RR

itself and MPLS forwarding function is enabled on

RR, as long as label is distributed to RR address

and the address is advertised, VPN devices can

communicate with each other. However, all VPN

traffic are forwarded by RR, RR will become the

bottleneck in the network.

4 SummaryIn application of intra-AS MPLS VPN, there may

be multiple links between ASBRs. For common IP

data forwarding, MPLS load balancing can be used

on these links. The steps are described below.

1. Implement load balancing of loopback

routes on these links.

2. Establish EBGP neighbor relationship

between ASBRs based on loopback addresses.

To implement MPLS load balancing of intra-

AS MPLS VPN, there is a third step. It is to enable

MPLS forwarding function on each links of ASBR.

This is to establish LSP tunnels based on loopback

address between ASBRs.

MPLS VPN meets the privacy requirement

of VPN by establishing tunnels through MPLS

sw i tch ing techno logy. PE dev ices

exchange VPN route information and label

information through MP-BGP. Messages

are encapsulated with MPLS packet

headers before transmission. To avoid

leaking messages to other devices, it

is necessary to establish an outer layer

tunnel directly or indirectly between PE

devices. This is the basic thought of MPLS

VPN.

In fact, the technologies and options

can be used flexibly. For example, in

OPTION-C, instead of distributing public

network labels through BGP in AS, it is

allowed to broadcast address of peer PE

device to IGP routing table directly and

then distribute labels through LDP.

In a word, MPLS VPN technology can

be used flexibly and the options can be

used together. For example, in application

o f Ca r r i e r ’s Ca r r i e r ne two rk , use

OPTION-C in network of level 1 service

operator and use OPTION-B in network

of level 2 service operator. As long as the

technology is used reasonably, expectant

goal can be achieved. ■

zte

Documents

pressing exch button

system halted file

designated web page

fixed ip addresses

window operating system

show arp command

hyper terminal attached

show run command