Sie sind auf Seite 1von 43

Preface

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

Maintenance Experience
Bimonthly for Data Products No.6 Issue 153, February / 2009

Maintenance Experience Editorial Committee

Five Maintenance Cases of ZTE's Data Products


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

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: doc@zte.com.cn. Thank you for making ZTE a part of your telecom experience! Maintenance Experience Editorial Committee ZTE Corporation February, 2009

Maintenance Experience Newsroom


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: doc@zte.com.cn Technical Support Website: http://ensupport.zte. com.cn

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

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server


Huang Zhiyan / ZTE Corporation
Key words: ZXUAS, 10600, 10800E, routine maintenance

1 ZXUAS 10800E Hardware Check


ZXUAS 10800E hardware check includes the following contents. TRACK indicators of active and standby BSFC3 boards are constantly on (the indicators may flash according to line clock status). 1.1.3 Abnormal Situation ALM 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 Processing When 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

1.1 Indicators on Front Panel of Rack


1.1.1 Checking Content Check 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 Situation RUN 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,

Maintenance Experience

www.zte.com.cn

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 halted file is generated.

1.3.3 Abnormal Situation ALM indicators of interface cards are constantly on. 1.3.4 Abnormal Situation Processing When 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 Check


ZXUAS 10600 hardware check includes the following contents.

1.2 Indicator of BIC Card


1.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 Situation RUN indicator (green) is on, and ALM indicator (red) is off. 1.2.3 Abnormal Situation ALM indicator of BIC card is constantly on. 1.2.4 Abnormal Situation Processing When 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.1 Indicators on Front Panel of Rack


2.1.1 Checking Contents Check 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 Situation RUN 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 Situation ALM indicator of active BUPC board is constantly on. ALM indicator of BNPCT board is constantly on.

1.3 Indicators of Interface Cards


1.3.1 Checking Content Check whether the indicators of interface cards on back panel of ZXUAS 10800E rack are normal. 1.3.2 Normal Situation RUN indicators (green) are on, and ALM indicators (red) are off (indicators of interface cards are below NP panel).

Data Products

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

Four indicators of BNPCT board flash at random. 2.1.4 Abnormal Situation Processing When 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.

indicator (red) is off. 2.2.3 Abnormal Situation ALM indicator of BIC card is constantly on. 2.2.4 Abnormal Situation Processing When 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 Cards


2.3.1 Checking Content Check whether the indicators of interface cards on back panel of ZXUAS 10600 rack are normal. 2.3.2 Normal Situation RUN indicators (green) are on, and ALM indicators (red) are off (indicators of interface cards are below NP panel). 2.3.3 Abnormal Situation ALM indicators of interface cards are constantly on. 2.3.4 Abnormal Situation Processing When 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 halted file is generated.

3 System Running Check


System running check includes the following contents.

3.1 Configuration Information


3.1.1 Checking Content Configuration information on device is viewed with show run command. 3.1.2 Normal Situation In 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.

2.2 Indicator of BIC Card


2.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 Situation RUN indicator (green) is on, and ALM

Maintenance Experience

www.zte.com.cn

3.1.3 Abnormal Situation ZXUAS#show run Building 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-189572 snmp-server location No.889 bibo Rd. pudong District, Shanghai, China snmp-server packetSize 1400 snmp-server engine-id 830900020300010289d64401 snmp-server view DefaultView system included snmp-server view AllView internet included ! logging on logging buffer 200 logging mode FULLCYCLE logging console NOTIFICATIONS logging level NOTIFICATIONS ! line console idle-timeout 120 Configuration information displayed on device is incomplete. Configuration information displayed is not consistent with the content that users configured. 3.1.4 Abnormal Situation Processing When configuration information 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 configuration information 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, reconfigure 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.

Data Products

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

3.2 Interface Information


3.2.1 Checking Content View interface status with show ip interface brief command. 3.2.2 Normal Situation In normal situation, the following information (or similar information) is displayed. The statuses of interface must be up. ZXUAS#show ip interface brief interface IP-Address gei_3/1 gei_3/2 unassigned unassigned gei_3/1.1 172.31.129.1 Mask unassigned unassigned AdminStatus PhyStatus Protocol up up up up down up up up down up

the configuration of other parameters. For the detailed configuration, refer to command manuals. If the problem still exists, contact to ZTE customer support center for further processing.

3.3 Port Traffic


3.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 Situation In 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 5984 pps 300 seconds output rate 1588616 Bps, 2426 pps Interface peak rate : input 3336705 Bps, output 9655627 Bps Interface utilization: input 12% Input: Packets : 18856871211 3577239232421 Unicasts : 4212281941 Multicasts: 15482672 Broadcasts: 1744204710 64B : 765621284 65-127B : 3457875708 512-1023B : 128-255B : 144996806 2 5 6 - 5 11 B : 1 6 8 0 8 3 0 8 6 548572994 1024-1518B: 1072082442 Bytes: 7%, output 986433 Bps,

255.255.255.252 up

loopback1 211.95.168.135 255.255.255.255 up 3.2.3 Abnormal Situation

AdminStatus 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 Processing When 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 configuration information on the interface. Parameters may be configured incorrectly or the parameters are not configured. Meanwhile, pay attention to

Maintenance Experience

www.zte.com.cn

Undersize: 0 ERROR : 14 Output:

Oversize : 5

CRC-

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.

Packets : 8123619305 4636044787350

Bytes:

3.4 Utilization of CPU and Memory


3.4.1 Checking Content To view utilization of CPU and memory, use show process command in privilege mode. 3.4.2 Normal Situation Take ZXUAS 10600 as an example. The following information is displayed.

Unicasts : 3392041984 Multicasts: 0 Broadcasts: 436610025 64B : 452201789 65-127B : 3840983938 512-1023B : 128-255B : 436380539 2 5 6 - 5 11 B : 2 3 6 3 9 7 7 5 2 Oversize : 0 3.3.3 Abnormal Situation In 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 Processing If 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:

636055401 1024-1518B: 2521647643

ZXUAS#show process CPU RPU 2 MPU 2 SFC 2 NPC 1 NPC 3 NPC 7 NPC 8 5s 0% 0% 2% 0% 0% 0% 0% 30s 0% 0% 2% 1% 0% 0% 0% 2m 30s max total memory buffer utility memory utility 23% 90% 8% 50% 53% 53% 60% 512M 512M 64M 101M 101M 101M 101M 46% 30% 59% 84% 84% 84% 84% utility 0% 0% 0% 0% 0% 0% 0% 0% 0% 2% 6% 0% 7% 1% utility utility utility

In normal situation, CPU utilization sampled at 5s, 30s and 2m must not be more than 50%. 3.4.3 Abnormal Situation CPU utilization is high, reaching 80%~90%. 3.4.4 Abnormal Situation Processing If 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

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

Data Products

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

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.

the peer device. If there is no problem about configuration, contact to ZTE customer support center for further processing.

3.6 System Log


3.6.1 Checking Content To view the system log information, use show logging alarm command in privilege mode. 3.6.2 Normal Situation In 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: An alarm 18564 level 6 occurred at 17:26:42 10/25/2003 UTC sent by UPC(MPU) 2 %UDP: udp rcv packet has a invalid checksum description: An alarm 18754 level 5 occurred at 15:05:38 10/27/2003 UTC sent by NPC 4 %IP: Time out while reassemble IP datagram 3.6.3 Abnormal Situation Abnormal alarm information is displayed. Abnormal Situation Processing Common log items and their descriptions are given below.

3.5 Routing Table


3.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 Situation There 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 Situation When 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 Processing If dynamic route items change frequently 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

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.

Maintenance Experience

www.zte.com.cn

description: tcp rcv bad checksum This indicates that the checksum of received

the authentication with any non-mull user name and password. Abnormal Situation Users can not pass authentication with correct user name and password. No. 691 error information appears. No. 678 error information appears. Abnormal Situation Processing Check 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 whether the IP address resource of the device is enough. If the problem still can not be solved, please contact to ZTE customer support center for further processing.

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.8 Fixed IP Service


3.8.1 Checking Content Check whether users with fixed IP addresses can get on-line normally. 3.8.2 Normal Situation Users with fixed IP addresses can get on-line normally after the configuration of IP addresses manually. 3.8.3 Abnormal Situation Users with fixed IP addresses can not get on-line after the configuration of IP addresses manually. 3.8.4 Abnormal Situation Processing Check whether the configuration of iphost is correct. Check whether the VLAN configuration on the sub-interface connecting to users is correct. Check whether the VBUI binding on

3.7 Dial-up Service


3.7.1 Checking Content Users implement PPP dial-up in radius authentication mode, local authentication mode and none authentication mode. 3.7.2 Normal Situation In 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

Data Products

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

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. If the problem still can not be solved, please contact to ZTE customer support center for further processing.

3.10 VPDN Service


3.10.1 Checking Content Check whether VPDN users can dial up normally. 3.10.2 Normal Situation VPDN users can dial up normally. 3.10.3 Abnormal Situation VPDN users can not dial up normally. 3.10.4 Abnormal Situation Processing Check whether L2TP configuration 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.9 DHCP Service


3.9.1 Checking Content Check whether users can obtain IP addresses through DHCP. 3.9.2 Normal Situation Users can obtain IP addresses through DHCP and get on-line normally. 3.9.3 Abnormal Situation Users can not obtain IP addresses through DHCP, or they can not get online after obtaining IP addresses through DHCP. 3.9.4 Abnormal Situation Processing Check whether DHCP configuration is correct. Check whether the user is in the correct VLAN. Check whether the client is configured to forbid obtaining IP address automatically. If the user can obtain IP address through DHCP but fails to get on-line, check whether limit access policy is configured. Check whether correct DNS is distributed to the user. If the problem still can not be solved, please contact to ZTE customer support center for further processing.

3.11 Radius Butt Joint


3.11.1 Checking Content Check whether the communication with Radius server is normal. 3.11.2 Normal Situation In normal situation, the UAS device can ping to Radius authentication server and accounting server successfully with radius-ping accountinggroup command and radius-ping authenticationgroup command. Users can pass authentication with correct user name and password, and they are accounted normally. 3.11.3 Abnormal Situation The UAS device can not communicate with Radius server. Authentication state or accounting state is abnormal.

10

Maintenance Experience

www.zte.com.cn

3.11.4 Abnormal Situation Processing Check 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.2 Device Memory Abnormal Utilization


4.2.1 Checking Content Check memory utilization with show process command in global configuration mode for several times. 4.2.2 Normal Situation Memory utilization is steady, no more than 80%. 4.2.3 Abnormal Situation Memory utilization 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 Processing If 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 support center for further processing.

4 System Abnormity Processing


System abnormity processing includes the following contents.

4.1 Start up Device Failure


4.1.1 Checking Content Check device startup. 4.1.2 Normal Situation UAS device can be started up from FLASH normally. 4.1.3 Abnormal Situation UAS device can not be started up from FLASH normally. 4.1.4 Abnormal Situation Processing It 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.3 CONSOLE Port Log in Failure


4.3.1 Checking Content Use serial port on PC to connect CONSOLE port to log in to UAS device. 4.3.2 Normal Situation Users 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 Situation Users 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 Processing When 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

Data Products

11

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

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.

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.

4.4 Telnet Log in Failure


4.4.1 Checking Content Log in to UAS device through telnet. 4.4.2 Normal Situation When routes are through, users can log in to UAS device through telnet. 4.4.3 Abnormal Situation Users can ping to UAS successfully, but they fail to log in to UAS device through telnet. 4.4.4 Abnormal Situation Processing The possible reasons to cause the

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 support center for further processing.

12

Maintenance Experience

www.zte.com.cn

5 Maintenance and Troubleshooting of Ethernet Functions


Maintenance and troubleshooting of Ethernet functions include the following contents.

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

5.1 ARP Function Maintenance


5.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 Situation UAS 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 60.29.39.201 60.29.39.202 Age(min) Hardware Addr 0 - 00d0.d0c3.becb 00d0.d0c5.3a80 00e0.fc39.af15 00d0.d0c5.3a80 0012.3f01.2c3d Interface fei_1/1 fei_1/1 fei_3/1 fei_3/1 gei_2/2

221.239.126.49 6 221.239.126.50 - 10.1.10.201 4

5.1.3 Abnormal Situation UAS 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 Processing When 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

Data Products

13

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

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

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

5.4 DHCP Server Function Abnormity


5.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 Situation User can obtain IP address and network gateway information. 5.4.3 Abnormal Situation User fails to obtain IP address. 5.4.4 Abnormal Situation Processing Check 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

5.2 Aggregating Link Failure


5.2.1 Checking Content Check LACP state with show lacp <id> internal command. 5.2.2 Normal Situation In normal situation, Agg State is selected. 5.2.3 Abnormal Situation In abnormal situation, Agg State is unselected. 5.2.4 Abnormal Situation Processing Check 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 Aggregation


5.3.1 Checking Content Check whether there are packets lost on the aggregated links. 5.3.2 Normal Situation In normal situation, users can ping to destination address successfully and there is no packet lost. 5.3.3 Abnormal Situation Users can ping to destination address successfully but packets are lost. 5.3.4 Abnormal Situation Processing Check whether CRC ERROR 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

5.5 DHCP Relay Function Abnormity


5.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 Situation User can obtain IP address and network gateway information. 5.5.3 Abnormal Situation User fails to obtain IP address.

14

Maintenance Experience

www.zte.com.cn

User can obtain IP address but fail to obtain gateway information. 5.5.4 Abnormal Situation Processing When 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

6 Processing for Broadband Access Service Abnormity


Processing for broadband access service abnormity includes the following contents.

6.1 Dial-up Failure


6.1.1 Checking Content Check whether users can dial up to access to network with correct user name and password. 6.1.2 Normal Situation In normal situation, users can pass the authentication. 6.1.3 Abnormal Situation Users can not pass the authentication. 6.1.4 Abnormal Situation Processing If 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

5.6 Frequent VRRP Active/Standby Changeover


5.6.1 Checking Content Check VRRP related information with show vrrp command. 5.6.2 Normal Situation In 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 Situation VRRP active device and standby devices change over frequently. 5.6.4 Abnormal Situation Processing Check 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

Data Products

15

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

6.2 On-line Failure for Users with Fixed IP Address


6.2.1 Checking Content Check whether users with fixed IP addresses can get on-line normally after they configure IP addresses manually. 6.2.2 Normal Situation Users with fixed IP addresses can get on-line normally after they configure IP addresses manually. 6.2.3 Abnormal Situation Users with fixed IP addresses can not get on-line after they configure IP addresses manually. 6.2.4 Abnormal Situation Processing If users fail to ping to gateway address s u c c e s s f u l l y, p e r f o r m t h e f o l l o w i n g operations. Check whether physical links are normal. Check whether configuration of ip-host on VBUI is correct. Check whether configuration of subinterface is correct. Check whether VBUI is bound correctly. Check VLAN configuration on downlink 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. If the problem still exists after the

above operations, please contact to ZTE customer support center for further processing.

6.3 On-line Failure for DHCP Users


6.3.1 Checking Content Check whether users can obtain IP addresses and get on-line normally. 6.3.2 Normal Situation In normal situation, users can obtain IP addresses and get on-line normally. 6.3.3 Abnormal Situation Users can obtain IP addresses, but they fail to get on-line normally. 6.3.4 Abnormal Situation Processing When 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 authentication 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

6.4 Failing to Open Designated Web Page


6.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 Situation Users can open the designated web page after they obtain IP addresses and open IE browser. 6.4.3 Abnormal Situation Users fail to open the designated web page after they obtain IP addresses and open IE browser.

16

Maintenance Experience

www.zte.com.cn

6.4.4 Abnormal Situation Processing Check 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

6.6 Dial-up Failure for VPLS Users


6.6.1 Checking Content Check whether data packets can be transmitted normally between VPLS and peers. 6.6.2 Normal Situation Data packets can be transmitted normally between VPLS and peers. 6.6.3 Abnormal Situation Data packets can not be transmitted normally between VPLS and peers. 6.6.4 Abnormal Situation Processing Check 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

6.5 Dial-up Failure for VPDN Users


6.5.1 Checking Content Check whether VPDN users can dial up to access to network. 6.5.2 Normal Situation In normal situation, VPDN users can dial up to access to network. 6.5.3 Abnormal Situation VPDN users fail to dial up to access to network. 6.5.4 Abnormal Situation Processing It 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 with LNS normally and whether tunnel is established normally. Check LNS configuration and make sure there is enough IP address in IP pool. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

7 Route Abnormity Processing


Processing for route abnormity includes the following contents.

7.1 Invalid Static Routes


7.1.1 Checking Content Check route times with show ip route command. 7.1.2 Normal Situation In normal situation, static routes can be viewed with show ip route command. An example is shown below.

Data Products

17

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

ZXUAS#show ip route IPv4 Routing Table: Dest Mask Gw Interface Owner pri metric static 1 0 192.16.1.0 255.255.0.0 196.20.1.1 fei_1/5

7.2.4 Abnormal Situation Processing Check 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

7.1.3 Abnormal Situation Static 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.3 Establishment Failure of OSPF Neighbor Relationship


7.3.1 Checking Content Check OSPF neighbor state with show ip ospf neighbor command. 7.3.2 Normal Situation In normal situation, OSPF neighbor state is FULL. For broadcast network and Non-Broadcast Multi-Access (NBMA) network, the state of DROTHER devices can be 2-WAY. 7.3.3 Abnormal Situation OSPF neighbor is in other states. 7.3.4 Abnormal Situation Processing Check 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.2 Implementation Failure of Load Balancing Through Static Route


7.2.1 Checking Content Check 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.

18

Maintenance Experience

www.zte.com.cn

ZTE. If users fail to check, configure ip ospf mtuignore 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

check debugging information with debug isis command. If problem is not found according to debugging information, save the debugging information and contact to ZTE customer support center for further processing. Note: Debugging costs system 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.4 IS-IS Function Abnormity


7.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 Situation In normal situation, IS-IS adjacency information is displayed. An example is shown below. ZXUAS#show isis adjacency Interface SystemID State Level Holds NPA Priority L1 9 802.2 00:e0:63:06:05:c0 64 fei_1/1 0000.0a0a.0a0a UP

7.5 Establishment Failure of BGP Neighbor Relationship


7.5.1 Checking Content Check BGP neighbor relationship state with show ip bgp neighbor command. 7.5.2 Normal Situation In normal situation, the BGP neighbor relationship state is Established. 7.5.3 Abnormal Situation BGP neighbor relationship state is not Established. 7.5.4 Abnormal Situation Processing Ping 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, updatesource 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

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 7.4.3 Abnormal Situation Neighbors 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 Processing Check 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,

Data Products

19

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

is required to configure neighbor <ipaddress> 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

situation, routes can be aggregated successfully. A configuration example is shown below. 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 ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 subnet 10.2.0.0 255.255.0.0 ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 subnet 10.3.0.0 255.255.0.0

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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

7.6 Failure to Advertise BGP Aggregation Route


7.6.1 Checking Content Check routes that are advertised to BGP neighbors with show ip bgp neighbor out command. 7.6.2 Normal Situation In normal situation, BGP aggregation routes can be advertised. 7.6.3 Abnormal Situation BGP aggregation routes can not be advertised. 7.6.4 Abnormal Situation Processing View aggregation route configuration with aggregate-address <ip-address> <net-mask> [count <count>] [summaryonly] [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

7.7 Failure to Learn BGP Routes


7.7.1 Checking Content Check BGP routing table with show ip bgp route command. 7.7.2 Normal Situation In normal situation, UAS device can learn BGP routes from neighbors. An example is shown below. ZXUAS#show ip bgp route Routes of bgp: status codes: *valid, >best,i-internal Origin 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 ?

20

Maintenance Experience

www.zte.com.cn

7.7.3 Abnormal Situation UAS device fails to learn BGP routes from neighbors. 7.7.4 Abnormal Situation Processing Check 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

7.8 Route Loop


7.8.1 Checking Content Ping to an IP address in the network. 7.8.2 Normal Situation Users can ping to the IP address successfully. 7.8.3 Abnormal Situation System returns result with TTTT, indicating that there is a route loop. 7.8.4 Abnormal Situation Processing Route 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 uplink 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

8 Processing for Other Function Abnormity


Processing for other function abnormity includes the following contents.

8.1 Processing for PIM-SM Function Abnormity


8.1.1 Checking Content Configure PIM-SM and then simulate a terminal user at user side to receive multicast packets. 8.1.2 Normal Situation The user can receive multicast packets. 8.1.3 Abnormal Situation The user fails to receive multicast packets. 8.1.4 Abnormal Situation Processing Check whether the PIM-SM 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

Data Products

21

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

group-address <ip-address> command. Check interaction information of PIM-SM protocol with debug ip pimsm command. Check whether user circuit is 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. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

PE1#show ip rout vrf vpn1 IPv4 Routing Table: Dest Mask Gw Interface Owner fei_1/1 static fei_1/1 direct pri metric 1 0 0 0 0 20 0 3.3.3.3 255.255.255.255 10.1.1.2 10.1.1.0 255.255.255.252 10.1.1.1 10.1.1.1 255.255.255.255 10.1.1.1

4.4.4.4 255.255.255.255 172.10.1.2 fei_1/2 bgp

fei_1/1 address 0

11.1.1.0 255.255.255.252 172.10.1.2 fei_1/2 bgp 11.1.1.1 255.255.255.255 172.10.1.2 fei_1/2 bgp

20 0 20 0

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 vpn1 Routes of vpn: status codes: *valid, >best, s-stale

8.2 Maintaining MPLS L3VPN


8.2.1 Checking Content Check MPLS VPN information with the following commands. show ip rout vpn show ip rout vrf <vrf> show ip protocol routing vrf <vrf> show ip bgp neighbor 8.2.2 Normal Situation VPN routes from peer PE can be viewed with show ip route vpn. An example is shown below.

Dest *> 3.3.3.3/32 *> 4.4.4.4/32

NextHop 10.1.1.2 172.10.1.2

Intag 20 18 17 16 19 21

Outtag notag 19 notag notag 17 16

RtPrf Protocol 1 20 0 0 20 20 static bgp-ext connected connected bgp-ext bgp-ext

*> 10.1.1.0/30 10.1.1.1 *> 10.1.1.1/32 10.1.1.1 *> 11.1.1.0/30 172.10.1.2 *> 11.1.1.1/32 172.10.1.2

In the result of show ip bgp neighbor command, neighbor relationship state is Established. 8.2.3 Abnormal Situation VPN is not through and VRF routing table is wrong. 8.2.4 Abnormal Situation Processing Check 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.

PE1# show ip rout vpn Routes of vpn: Dest NextHop Type ASN Addr Peer 0 0 0 100 1 100 1 100 1 100 1 100 1 100 1 0.0.0.0 0.0.0.0 0.0.0.0 172.10.1.2 172.10.1.2 172.10.1.2 3.3.3.3/32 10.1.1.2 10.1.1.0/30 10.1.1.1 10.1.1.1/32 10.1.1.1

4.4.4.4/32 172.10.1.2 0 11.1.1.0/30 172.10.1.2 0 11.1.1.1/32 172.10.1.2 0

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

22

Maintenance Experience

www.zte.com.cn

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 following LDP configuration is configured.

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

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.

8.4 Application Failure of ACL Configuration to Interface


8.4.1 Checking Content Configure ACL and apply the configuration to an interface. 8.4.2 Normal Situation ACL configuration can be applied to the interface and the configuration is valid. 8.4.3 Abnormal Situation System prompts error information when ACL configuration is applied to an interface. 8.4.4 Abnormal Situation Processing Check 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 is indispensable for the interface, try to combine the rules of two ACL configurations. If this problem still exists after the above operations, please contact to ZTE customer support center for further processing.

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. If the problem still exists after the above

operations, please contact to ZTE customer support center for further processing.

8.3 Invalid ACL Configuration


8.3.1 Checking Content Check ACL configuration. 8.3.2 Normal Situation ACL configuration is valid. 8.3.3 Abnormal Situation ACL configuration is invalid. 8.3.4 Abnormal Situation Processing Check 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

8.5 Failure to Obtain Device Information through SNMP


8.5.1 Checking Content Check SNMP configuration information with show snmp config command. 8.5.2 Normal Situation There is configuration of a community with ro or rw privilege, containing AllView, for example, snmp-server community <community-name> view AllView ro.

Data Products

23

February 2009

Issue 153

Routine Maintenance of ZXUAS 10600&10800E Broadband Access Server

8.5.3 Abnormal Situation There is no configuration of a community or there is community without AllView. 8.5.4 Abnormal Situation Processing Configure a community with AllView, and make the community read information. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

8.6.2 Normal Situation There is configuration of a community with rw privilege, containing AllView, for example, snmpserver community <community-name> view AllView rw. 8.6.3 Abnormal Situation There is no configuration of a community with rw privilege or there is community without AllView. 8.6.4 Abnormal Situation Processing Configure an rw community with AllView, and make the community write information on NMS. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.

8.6 Configuration Failure of Device through SNMP


8.6.1 Checking Content Check SNMP configuration information with show snmp config command.

24

Maintenance Experience

www.zte.com.cn

Failing to Get on-line with Fixed IP Address


Wang Yufeng / ZTE Corporation
Key words: SVLAN, UAS, QinQ, double layer labels, users of fixed IP addresses

1 Network Topology
SVLAN 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 Analysis
I n t h e n e t w o r k t o p o l o g y, T 6 4 G connected UAS 10600 through dual uplinks. As few packets could reach gateway and network management of T16C-1 and T16C-2 that transmit transparently to
Figure 1. Network Topology

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

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 Situation
Configurations on devices were changed correctly. However, users in Internet bar said

Data Products

25

February 2009

Issue 153

Failing to Get on-line with Fixed IP Address

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/2 description to-lichuanT16C-1 switchport hybrid native vlan 5 switchport hybrid vlan 5 untag switchport qinq customer interface gei_4/5 description to-lichuanT16C-2 switchport hybrid native vlan 5 switchport hybrid vlan 5 untag switchport qinq customer interface fei_2/1 description to_lichuan2403_1 switchport hybrid native vlan 1 switchport hybrid vlan 5 untag switchport hybrid vlan 4094 untag switchport 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 Solution
Engineers modified the configuration of gei_4/5 and gei_4/2 on T64G, as shown below. interface gei_4/2 description to-lichuanT16C-1 switchport hybrid native vlan 107 switchport hybrid vlan 5 untag switchport hybrid vlan 4094 untag switchport qinq customer interface gei_4/5 description to-lichuanT16C-2 switchport hybrid native vlan 5 switchport hybrid vlan 5 untag switchport hybrid vlan 4094 untag switchport 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 5 vlan 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 Summary
When a switch connects to a UAS device through dual up-links, do not configure 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.

26

Maintenance Experience

www.zte.com.cn

IP Address Pool Configuration


Liu Peng / ZTE Corporation
Key words: IP address pool, BAS, VBUI, user domain

1 Network Topology
As 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 ip address 222.138.100.1 255.255.254.0 secondary ip address 222.138.70.1 255.255.254.0 secondary ip address 219.154.108.1 255.255.254.0 secondary description for_PPPOE_dial ip pool 1 pppoe_pool1 115.56.144.2 115.56.147.254 ip pool 2 pppoe_pool2 219.154.98.2 219.154.99.254 ip pool 3 pppoe_pool3 219.154.108.2 219.154.109.254 ip pool 4 pppoe_pool4 222.138.70.2 222.138.71.254 ip pool 5 pppoe_pool5 222.138.100.2 222.138.101.254
Figure 1. Network Topology

Configuration of VBUI2 is shown below. interface vbui2 ip address 10.254.64.1 255.255.255.0 description for_help ip pool 21 help_pool1 10.254.64.2 10.254.64.254

2 Malfunction Situation
There are multiple dial-up user domains configured on BAS device. In different domains, users are required to obtain IP addresses in

Data Products

27

February 2009

Issue 153

IP Address Pool Configuration

Configuration of VBUI3 is shown below. 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 Configuration of domain 2 is shown below. domain 2 alias cnc subscriber-template ip address interface vbui2 Configuration of domain 3 is shown below. domain 3 alias iptv subscriber-template ip address interface vbui3 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, subscribertemplate of domain 1 is bound to VBUI1, users in domain 1 still can not obtain the new addresses in the new VBUI interface.

3 Solution
In 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. Configuration of VBUI2 is shown below.

28

Maintenance Experience

www.zte.com.cn

interface vbui2 ip address 10.254.64.1 255.255.255.0 description for_help ip pool 21 help_pool1 10.254.64.2 10.254.64.254 domain 2 Configuration of VBUI3 is shown below. 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 domain 3 Meanwhile, add a new VBUI interface, VBUI4. Configuration of VBUI4 is shown below. 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 ip pool 6 pppoe_pool6 61.53.106.2 61.53.106.254 domain 1 ip pool 7 pppoe_pool7 61.53.107.2 61.53.107.126 domain 1

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 dialup service users and users in a domain want to obtain addresses form different VBUI interfaces, it 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 subscribertemplate 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.

4 Experience Summary
For 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

Data Products

29

February 2009

Issue 153

Link Aggregation Configuration on UAS2500S


Li Yong / ZTE Corporation
Key words: 2500S, 2826S, link aggregation, LACP

1 Network Topology
It is required to configure link aggregation in VLAN 100 between 2500S and 2826S, as shown in Figure 1.

2 Configuration Process
Configuration of 2500S is shown below. UAS#set vlan 100 create UAS#show trunking TrunkingAgList: --------------1 UAS#show vlan 100 VlanVersionNumber:1 ---------------------------VlanId : 100 VlanStaticName : StaticEgressPorts : (slot-1) 1 (slot-2) 1 2 ForbiddenEgressPorts: 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 1 UAS#set vlan 100 slot 2 port 2 op 1 UAS#no set vlan 1000 slot 2 port 1 op 1 /*delete vlan 1000 on slot 2 port 1/ MaxVlanId:4094 NumVlans:5 MaxSupportedVlans:4094

Figure 1. Network Topology

30

Maintenance Experience

www.zte.com.cn

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 UAS#set trunking slot 2 port 2 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. UAS#set trunking slot 2 port 1 agport 0 /*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. UAS#set trunking slot 2 port 1 agport 1 UAS#set trunking slot 2 port 2 agport 1 Configuration of 2826S is shown below. zte(cfg)#show run Software version: 1.1 Switch's Mac Address: 00.d0.d0.fc.76.f1 ! syslocation No.68_Zijinghua_Road,Yuhuatai_Di strict,Nanjing,CHINA create user admin loginpass B612AD6F2259089A79740AD7CB5A 38BF line-vty timeout 10 ! ! set port 2 pvid 100 ! set vlan 1 add port 1-24 untag

set vlan 1 add trunk 1-8 untag set vlan 100 enable set vlan 100 add port 2 untag set vlan 100 add port 1,12 tag set vlan 100 add trunk 1 tag ! ! ! set lacp enable set lacp aggregator 1 add port 1,12 set lacp aggregator 1 mode static ! ! create community public public create view zteView include 1.3.6.1 set community public view zteView ! LACP must be set to static on 2826S. Otherwise, information 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 LacpActive ----------- -------1 True 12 True After the configuration, users can pass authentication and obtain IP addresses in address pools. After users get online 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 Static Long 1 Static Long ----------- ----------- ----------- GroupNum GroupMode LacpTime

Data Products

31

February 2009

Issue 153

Processing of IS-IS Malfunction on ZXUAS 10600


Wang Yufeng / ZTE Corporation
Key words: UAS, IS-IS, metric-style, narrow, wide

1 Network Topology
ZXUAS 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 Situation
IS-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.

Figure 1. Network Topology

32

Maintenance Experience

www.zte.com.cn

3 Malfunction Analysis
Engineers could not view the configurations on HW NE80 devices. They only viewed isis circuittype 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-2only to isis circuit-type level-1-2, and redistributed direct-connected routes. But the problem still existed.

isis 1 is-level level-2 cost-style wide network-entity 49.0898.2180.7714.80 02.00 filter-policy 2003 import default-route-advertise preference 115 interface GisgabitEthernet9/0/4 ip address 218.77.150.137 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.

4 Solution
With the help of office staff, engineers obtained related configuration on HW NE80 devices, as shown below.

5 Experience Summary
By 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.

Data Products

33

February 2009

Issue 153

MPLS MP-BGP VPN Configuration


Zhu Yanbo / China Unicom
Key words: MPLS, BGP, VPN

1 MPLS VPN Overview


VPN 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 intraAS MPLS VPN services have developed maturely. 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.

Figure 1. MPLS L3VPN Packet

34

Maintenance Experience

www.zte.com.cn

I n t h e p a c k e t h e a d e r, M P L S a d d r e s s 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. After MPLS encapsulation, 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 (MPBGP). 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. If the same RD is distributed 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, MPBGP does not enable load balancing on multiple links. If RDs and IPv4 addresses of 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 attribute of BGP Community. It is used to introduce VPN instance. The application of RT makes MPLS VPN network more flexible. 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

Data Products

35

February 2009

Issue 153

MPLS MP-BGP VPN Configuration

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.
Figure 3. Next-Hop Address Aggregation Figure 2. Part Information of a MP-BGP Update Message

2 Intra-AS MPLS VPN


Figure 4 shows the topology of an intra-AS MPLS VPN network.

Figure 4. Intra-AS MPLS VPN Network Topology

36

Maintenance Experience

www.zte.com.cn

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.
Address VPN-1: 2.2.2.2 Next-Hop PE-B Label X

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 VPN


There are three types of topologies of inter-AS MPLS VPN network:

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.
Address PE-B Next-Hop INTF-A Label Y

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

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

Data Products

37

February 2009

Issue 153

MPLS MP-BGP VPN Configuration

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

When ASBR learns VPN route 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. Before advertising VPN route 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 NextHop 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 vendors work as ASBR devices in OPTION-B, local ASBR generates an address in local routing table for interconnection with 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

38

Maintenance Experience

www.zte.com.cn

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.

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.
Address VPN-1: 2.2.2.2 Next-Hop PE-B Label X

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.
Address PE-B
Figure 7. OPTION-C Network Topology

Next-Hop AS-A ASBR

Label Y

3. PE-A searches for forwarding information of ASBR in AS-A (next hop of PE-B), as shown below.
Address AS-A ASBR Next-Hop INTF-A Label Z

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.

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

Data Products

39

February 2009

Issue 153

MPLS MP-BGP VPN Configuration

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.

s w i t c h i n g t e c h n o l o g y. P E d e v i c e s 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 of Carrier s Carrier network, 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.

4 Summary
In 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 intraAS 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

40

Maintenance Experience

Das könnte Ihnen auch gefallen