preface - ztezte.by/magazine/maintenance experience, issue102(data products).pdf · deputy...

PrefaceMaintenance ExperienceEditorial Committee

Director: Zhou Susu

Deputy Director: Chen Jianzhou

Editor-in-Chief: Yang Cheng

Editors:Jiang Guobing, Zhang Shoukui, Wu Feng,

Yuan Yufeng, Tang Hongxuan, Chen Huachun,

Li Gangyi, Gu Yu, Song Jianbo, Tian Jinhua,

Du Jianli, Qu Ruizheng, Zhang Zhongdong,

Liu Xianmin, Wang Zhaozheng, Liu Wenjun,

Wang Yapping, Lei Kun, Wang Tiancheng, Cai

Hongming

Technical Senior Editors:Hu Jia, Yu Chengjun, Bai Jianwen

Executive Editor:Zhang Fan

Maintenance ExperienceNewsroom

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

Industrial Park, Nanshan District,

Shenzhen, P.R.China

Postal code: 518057

Contact: Song Chunping

Email: [email protected]

Tel: +86-755-26770600,26771195

Fax: +86-755-26772236

Document support mail box: [email protected]

Technical support website: http://ensupport.zte.

com.cn

Maintenance Experience Editorial CommitteeZTE CorporationMay, 2008

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

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

Nine Maintenance Cases of ZTE's Data Products

Have you examined your service polices and procedures lately? Are you confident that your people are using all the tools at their disposal? Are they trained to analyze each issue in a logical manner that provides for less downtime and maximum customer service? A close look at the cases reveals how to isolate suspected faulty or mis-configured equipment, and how to solve a problem step by step, etc. As success in commissioning and service is usually a mix of both discovery and analysis, 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 build, in all levels, from office interns to veteran engineers, who work together to bring global focus into their daily work.

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

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

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

Maintenance ExperienceBimonthly for Data ProductsNo.23 Issue 102, May/2008

Contents

SuperVLAN Configuration ......................................................................................................................... 2

SVLAN Malfunction Processing............................................................................................................... 10

Malfunction Processing in VRRP and NAT Network................................................................................ 15

Malfunction on MPLS VPN Service ......................................................................................................... 18

Malfunction on Uplinks ............................................................................................................................ 20

Malfunction in Cluster Management ........................................................................................................ 27

3952 Connecting to MSG9000 GEB........................................................................................................ 30

IP Prefix-List Configuration ...................................................................................................................... 32

STP malfunction on 2826S Switch .......................................................................................................... 33

May 2008 Issue 102

Maintenance Experience2

⊙ Hui Zhirui, ZTE Corporation

SuperVLAN Configuration

1 SuperVLAN OverviewSupe rVLAN, a l so ca l l ed VLAN

aggregation, is a management technology

designed for opt imizat ion of saving

IP addresses. In a SuperVLAN, each

sub-VLAN is an independent multicast

channel. Multicast information can not

be exchanged among the different sub-

VLANs. To send the data to multiple

dest inat ion nodes, i t is required to

establish a dynamic VLAN agent. The

devices such as routers and switches

manage users in the VLAN through the

ARP agents. Therefore, there is no need

Key words: SuperVLAN, VLAN aggregation, sub-VLAN, address binding

to set an independent network segment for each

sub-VLAN. Instead, all sub-VLANs of the same

SuperVLAN share the same network segment. The

gateway of all users in each sub-VLAN is the IP

address of the SuperVLAN.

In the test SR project of Sichuan province

in 2005, to meet the requirements of users

and services, ZTE extended the functions of

SuperVLAN. Besides the basic functions of

SuperVLAN, ZTE developed the user security

functions such as user address binding and limiting

bandwidth of each user. This function provides

better security for SuperVLAN services, and makes

the user accesses more controllable. In addition, to

www.zte.com.cn

3Data Products

provide high stability and 99.99999% reliability for

the networks, ZTE routers and switches can realize

bindings of multiple links.

2 SuperVLAN FunctionsZTE routers and switches have the following

SuperVLAN functions:

Supporting GE/FE SuperVLAN function

Supporting SuperVLAN as an IP and the

access to the Layer 3 VPN

Supporting communications between the

users in different sub-VLANs (This function is

configurable.)

Supporting isolations of the users in different

sub-VLANs (This function is configurable.)

Supporting the upstream and downstream

speed limit of users in different sub-VLANs

Supporting to enable/disable to bind the IP

addresses of users in the SuperVLAN

Supporting up to 256 addresses bindings for

each user

Supporting ACL fi ltration function on the

SuperVLAN interfaces

Supporting multiple links bindings for upstream

in GE/FE

Supporting address bindings

3 Version ReleaseTable 1 shows the versions of ZTE routers and

switches that support functions of SuperVLAN,

VRF and the number of SuperVLAN groups.

Table 1. Device and SuperVLAN/VRF Versions

4 Working PrincipleSuperVLAN working principles have

three aspects:

Address binding configuration

The software of the routers and

sw i t ches se ts an address poo l o f

IP bindings on the sub interfaces of

the interfaces that are bound to the

SuperVLAN. The software creates an

index by IP addresses for the address pool

and sub interfaces. These IP addresses

are written in a chain table. For the multiple

links bindings for upstream, the IP address

or address pool is bound to multiple sub

interfaces. Therefore, the software uses

the chain table to store multiple sub

interfaces that are bound to the same IP

address. When the address or address

pool binding is deleted on a sun interface,

the software searches the binding table

and deletes all related information.

Software ARP learning flow

When a router or a switch receives

an ARP request message from a user,

the router or switch queries whether the

SuperVLAN which the received message

belongs to enables address binding. If

the SuperVLAN enables address binding,

the router or switch uses the source

IP address of the user indicated in the

message as an index entry to search the

Device SuperVLAN SuperVLAN+VRF Number of SuperVLAN Groups

GAR/ZSRThe version released in July, 2007

The version released in July, 2007

255

GER 03B version 03B version 255

T128/T64E All versions C19 versionsSince C58 version, the number is 1024; before it, the number is 64;

T160G/T64G/T40G All versions D11P02 versions 255

5900/3900 All versions None 255

May 2008 Issue 102

Maintenance Experience�

chain table of address binding, and finds out the matching IP address and sub interface. If the

matching entry is found, the router or switch considers the user is legal, and then implements

normal ARP learning. Otherwise, the router or switch considers the user is illegal and discards the

ARP message.

Forwarding flow

When the hardware of the bottom layer receives an IP message from a user, the router or the

switch uses the VLAN and IP address in the message as an index entry to search address binding

table in the hardware of the bottom layer, and finds out the matching IP address, VLAN and

physical interface. If the matching entry is found, the router or switch considers the user is legal,

and then implements normal message processing. Otherwise, the router or switch considers the

user is illegal and discards the message.

5 SuperVLAN from Single Uplink to Router/Switch5.1 Network Topology

In VLAN C, users need a great many IP addresses, so configure an independent network

segment and gateway for VLAN C. In VLAN A and B, users need a few IP addresses, so configure

a SuperVLAN to share the same network segment and gateway. The topology is shown in Figure 1.

Figure 1. Network Topology1

5.2 SuperVLAN ConfigurationConfiguration on the router is as follows:

1. Create a SuperVLAN interface.

ZXR10(config)#interface supervlan1000

//create a supervlan 1000

ZXR10(config)#inter-subvlan-routing disable

//forbid users in the super to communicate with each other

www.zte.com.cn

5Data Products

ZXR10(config)#arp-broadcast disable

//disable ARP broadcast

ZXR10(config)#ip-pool-filter enable

//Enable IP address binding. This function is used together with ARP broadcast switch. It is

adviced to enable this function to reduce the number of ARP broadcast messages.

ZXR10(config)#ip address 192.168.1.1 255.255.255.0

//configure the address of supvlan interface

2. Configure the SuperVLAN interface.

ZXR10(config)#interface gei_1/2.100

ZXR10(config-if)#encapsulation dot1Q 100

ZXR10(config-if)#supervlan 1000

ZXR10(config-if)#ip supervlan pool 192.168.1.5 192.168.1.6

//Configure address binding. Users accessing through VLAN 100 are only allowed to use

IP addresses 192.168.1.5 and 192.168.1.6. If only one address is allowed to use, configure

the start address and end address the same.

Configuration on the switch:

1. Create a SuperVLAN. The configuration is the same as the configuration on the router.

2. Configure interface data. Add the port to a SubVLAN with tag.

ZXR10(config)#interface gei_1/2

ZXR10(config-if)#switchport mode trunk

ZXR10(config-if)#switchport trunk vlan 100

3. Configure the SubVLAN to be attached to the SuperVLAN.

ZXR10(config)#vlan 100

ZXR10(config)#supervlan 1000

ZXR10(config)#ip supervlan pool 192.168.1.5 192.168.1.6

//configure address binding

ARP message broadcast rules on SuperVLAN interfaces are as follows:

If ARP broadcast function is enabled on a SuperVLAN interface, the ARP message is

broadcasted to all SubVLAN interfaces.

If ARP broadcast function is disabled on a SuperVLAN interface, the ARP message is only

forwarded to the SubVLANs interfaces on which the pool is configured. If no SubVLAN is

configured pool, the ARP message will be discarded.

May 2008 Issue 102


ARP broadcast switch only affect the ARP request messages. If a router or a switch receives

the ARP request messages, no matter whether the switch or the router is enabled or disabled, the

router or the switch will respond to the requests.

Table 2 shows the results of combination uses of ARP broadcast switch and pool switch.

Table 2. Results of Combination Uses of the Two Switches

Arp broadcast switch

ip-pool-filter switch

SubVLAN pool

Service resultBroadcast

StormAbility to

prevent attacks

arp-broadcast disable

ip-pool-filter disable

Notconfigured

ARP messages are discarded. When ARP is timeout, the service is not through.

Not exist Weak

Configured Through Not exist Weak

ip-pool-filter enable

Notconfigured

Not through Not exist Strong

Configured Through Not exist Strong

arp-broadcast enable

ip-pool-filter disable

Notconfigured

Through Exit Weak

Configured Through Exit Weak


Notconfigured

Not through Exit Strong

Configured Through Exit Strong

www.zte.com.cn

7Data Products

6 SuperVLAN+VRF from Single Uplink to Router/Switch6.1 Network Topology

In VLAN C, users need a great many IP addresses, so configure an independent network

segment and gateway for VLAN C. In VLAN A and B, users need a few IP addresses, so configure

a SuperVLAN to share the same network segment and gateway. The topology is shown in Figure 2.

Figure 2. Network Topology2

6.2 SuperVLAN ConfigurationThe configuration on the router is as follows:

1. Create a SuperVLAN interface.

ZXR10(config)#interface supervlan1000

ZXR10(config)#inter-subvlan-routing disable

ZXR10(config)#arp-broadcast disable

ZXR10(config)#ip-pool-filter enable

ZXR10(config)#ip vrf forwarding test

//bind the supervlan and vrf test, that is, users access to layer 3 VPN test through the

supervlan

ZXR10(config)#ip address 192.168.1.1 255.255.255.0

2. Configure the SuperVLAN interface.

ZXR10(config)#interface gei_1/2.100

ZXR10(config-if)#encapsulation dot1Q 100

ZXR10(config-if)#supervlan 1000

ZXR10(config-if)#ip supervlan pool 192.168.1.5 192.168.1.6

May 2008 Issue 102


The configuration on the switch is as follows:

1. Create a SuperVLAN. The configuration is the same as the configuration on the router.

2. Configure interface data. Add the port to a SubVLAN with tag.

ZXR10(config)#interface gei_1/2

ZXR10(config-if)#switchport mode trunk

ZXR10(config-if)#switchport trunk vlan 100

3. Configure the SubVLAN to be attached to the SuperVLAN.

ZXR10(config)#vlan 100

ZXR10(config)#supervlan 1000

ZXR10(config)#ip supervlan pool 192.168.1.5 192.168.1.6

//configure address binding

7 SuperVLAN Maintenance7.1 SuperVLAN Service in Internet Bar

In the Internet bars, there are usually different kinds of computer viruses and network attacks.

To make the service runs normally, pay attention to the following items:

Enable the address binding function of SuperVLAN on the routers or switches. This is to avoid

the addresses for legal users to be embezzled. When the address binding function is enabled

on the Supervlan interface, corresponding address bindings should be configured on all sub

VLAN interfaces belonging to the SuperVLAN interface.

Configure ACL to filter IP broadcast, IP network segment broadcast and data packets with

viruses that attack the known ports.

For the data packets with the destination of local SR gateway, configure ACL to filter all

packets to local except the ICMP packets.

Configure ACL to filter the data packets with the source addresses of local addresses.

The configuration of ACL is shown below:

ip access-list extended 11�

permit icmp any 192.168.1.1 0.0.0.0

//192.168.1.1 is the IP address of Supervlan interface

deny ip any 221.236.35.1 0.0.0.0

deny ip any 22�.0.0.0 31.255.255.255

permit ip 192.168.1.0 0.0.0.255 any

permit ip 192.168.1.0 0.0.0.255 any

www.zte.com.cn

9Data Products

7.2 SuperVLAN Maintenance CommandsFor SuperVLAN maintenance, use the following commands.

1. show arp supervlan1000

This command is used to display the relationship between MAC address and IP address of

a user. Versions of high end router after C58 support to display the sub interfaces that the users

use. Versions before C58 only support to display the SuperVLAN interfaces.

An example of this command is shown below:

ZXR10#show arp supervlan1000

Arp protect interface is disabled . The count is 3

Address Age(min) Hardware Addr Interface Sub-interface

192.168.243.132 5 0090.c2cc.9c50 supervlan1000 gei_3/2.2

192.168.243.205 5 0090.c2cc.9b9a supervlan1000 gei_3/2.44

192.168.243.195 5 0090.c2cc.9ae1 supervlan1000 gei_3/2.29

2. show supervlan 1000

This command is used to display the information of sub interfaces belonging to Supervlan

1000.

An example of this command is shown below:

ZXR10#show supervlan 1000

interface supervlan1000

inter-subvlan-routing enable

arp-broadcast disable


subInterface gei_3/2.1 enc-vlan-id 3128






……

■

May 2008 Issue 102


Network TopologyMult iple T�0G switches (with no

network processors) connect to a T6�G

switch (with a network processor). Each

T�0G switch downlinks to a DSLAM device

with client. A server connects to the T6�G

switch through a DSLAM device. The

T6�G switch and the T�0G switches are

configured with transparent transmission

function for single label and double labels.

All clients and the server are in the same

network segment and belong to Vlan 615.

The gateway of the clients and the server

is configured on HW 5200G. The network

topology is shown in Figure 1.

SVLAN Malfunction Processing⊙ Hu Wen, ZTE Corporation

Figure 1. Network Topology

Key words: ARP, MAC address drifting, QinQ, SVLAN

www.zte.com.cn

11Data Products

Malfunction SituationOne day, clients said that when they uploaded data to the server, the transmission was often

interrupted or they failed to connect to the server. When the communications between the clients

and the server were interrupted, other PPPOE users could get online normally.

Malfunction Analysis1. Engineers checked the configuration, CPU and port information of the T64G switch and

T40G switches. They did not find any mistakes.

2. Engineers input show logging alarm command, and still found no mistakes.

3. By default, the function of MAC address drifting alarm is disabled on T6�G switch and T�0G

switch. Therefore, engineers could not judge whether there was a loop. Engineers enabled the

function and configured static bindings to the MAC address of the server 0006.5b3f.5c4e on the

T6�G switch and T�0G switches.

The configuration of the T64G switch is shown below:

T64G(config)#mac add permanent 0006.5b3f.5c4e interface fei_1/8 vlan 615

The configurations on the T40G switches are the same. Here take T40G-1 as an example.

T40G-1(config)#mac add permanent 0006.5b3f.5c4e interface gei_2/1 vlan 615

A moment later, the client connecting to the T40G-1 switch through Fei_1/1 said that the

problem still existed when he uploaded data to the server.

4. Engineers configured the IP addresses for the interface vlan 615 on the T64G switch and

T�0G-1 switch, and pinged to the server on the client PC with the malfunction. After a moment, the

ping messages were interrupted. And then, the ping messages recovered. This situation repeated.

When engineers pinged to the server on the T6�G switch, the situation was the same.

5. Engineers checked the ARP table on the client PC with the malfunction. They found that the

PC could learn the MAC address of the destination correctly. Engineers cleared the ARP table on

the PC to make the PC learn the MAC address again. The PC still could learn the MAC address

correctly.

6. Engineers found that when the PC could not ping to the T6�G switch successfully, the

T6�G switch could not ping to the PC either. At the same time, the T6�G switch failed to learn the

MAC address of the client PC, while T�0G-1 switch could. Sometimes, the MAC address drifting

alarm of the client PC appeared on the T�0G-1 switch, as shown below:

An alarm 22789 level 6 occurred at 16:31:13 08/31/2007 UTC sent by MEC 1 %MAC%

<MAC Table> <MAC 00E0.A004.8170 VLAN 4044> From Port fei_1/2 To Port fei_1/1

An alarm 22789 level 6 occurred at 16:31:23 08/31/2007 UTC sent by MEC 1 %MAC

<MAC Table> <MAC 00E0.A004.8170 VLAN 4044> From Port fei_1/1 To Port fei_1/2

The alarm indicated that the MAC address of the client PC was drifting between Fei_1/1 and

Fei_1/2 (the Native VLAN of Fei_1/1 and Fei_1/2 is 4044). Therefore, engineers considered that

the malfunction was on the T�0G-1 switch or the access to the T�0G-1 switch.

May 2008 Issue 102


7. Engineers bound the MAC address of the client PC to the T�0G-1 switch to prevent the

drifting. The malfunction still existed. Engineers checked the learning of the server MAC address

on the T�0G-1 switch. They found the following information:

MAC_Address port vid stc per toS srF dsF Frm vpnid Time

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

0006.5b3f.5c4e fei_1/2 4044 0 1 0 0 0 1 0 0:00:30:42

The information indicated that the MAC address of the server was learned from Fei_1/2 on

the T40G-1 switch. Therefore, the client PC sent data packets to Fei_1/2 instead of Gei_2/1. This

caused the malfunction.

SolutionEngineers configured static binding to the MAC address on the T�0G-1 switch, as shown

below:

T40G-1(config)#mac add permanent 0006.5b3f.5c4e interface gei_2/1 vlan 4044

The communication between the client and the server recovered. The client could upload data

to the server successfully.

Experience SummaryThe primary configuration of the T40G-1 switch is as follows:

interface fei_1/1

description tanshui-adsl

no negotiation auto

switchport mode hybrid

switchport hybrid native vlan �0��

switchport hybrid vlan 57 tag


switchport hybrid vlan 6�3 tag


switchport hybrid vlan 571 untag

switchport hybrid vlan �0�� untag

switchport qinq customer

!

interface fei_1/2

description hekou-adsl

no negotiation auto


www.zte.com.cn

13Data Products






switchport qinq customer

!

……

interface gei_2/1

description to-YangChunJiuJu-T64G-Gei_1/9

no negotiation auto

hybrid-attribute fiber



switchport hybrid vlan �3 tag

……







switchport hybrid vlan 1�73-1�79 tag



switchport qinq uplink

……

Clients connecting to Fei_1/1 and Fei_1/2 wanted to communicate with each other, so session

was not configured for single label transparent transmission of Vlan 615. This is about the

communication between Customer ports.

For switches without network processors, the MAC address of a Customer port is learned

in the Native Vlan. Therefore, the client PC learned the MAC address in Vlan �0��. The MAC

address of an Uplink port is learned in command Vlan, that is, in Vlan 615. In the single label

transparent transmission service, packets from the Customer port are broadcasted to all ports in

Native Vlan (Vlan �0��), unless the Native Vlan have learned the MAC address. Packets from

the Uplink port are also broadcasted to all ports of Vlans indicated in the packets, unless the

Vlan have learned the MAC address of the destination. When the malfunction occurred, the MAC

address of the server was learned by Fei_1/2 in Vlan 4044, so the T40G-1 switch forwarded the

packets to Fei_1/2 instead of Gei_2/1.

Why could Fei_1/2 in Vlan 4044 learn the MAC address of the server? One possible reason

May 2008 Issue 102

Maintenance Experience1�

was that there was a loop on Fei_1/2. The

switch broadcasted the packets from the

server to the clients, that is, to Fei_1/1

and Fei_1/2. When there was a loop on

Fei_1/2, Fei_1/2 could learn the MAC

address of the server. Another possible

reason was that there were MAC attacks

in the network connecting to Fei_1/2. In

these two situations, the MAC address

of the server was learned by different

Vlans. Even the port that learned the MAC

address was changed, there would not

be any alarms for MAC address drifting.

Therefore, when engineers configured

static binding to the MAC address of the

server in Vlan 615, the switch still could

learn the MAC address in Vlan �0��.

Why could the client PC learn the

MAC address of the server correctly?

It is because when the T�0G-1 switch

received the ARP broadcast message,

it broadcasted the message to all ports

in the Native Vlan, including Gei_2/1.

Therefore, the server could receive the

ARP request message, and the client PC

could learn the MAC address of the server.

When MAC address is timeout on the switch, the

communication between the client PC and the

server was interrupted.

To solve malfunctions such as this, perform the

following steps:

1. When the users in the sub VLANs do not

require communicating with each other, isolate

the downlink ports connecting to the switch; or

configure transparent transmission session on the

ports; or change the Native Vlans of the Customer

ports to be different VLANs.

2. In the topology shown in Figure , it is

recommended to isolate the ports connecting to the

T�0G switches. Communications between clients

and communications between the clients and the

server can be implemented through BRAS devices

as bridges.

3. Eliminate loops and MAC attacks.

�. If the above three steps can not be

implemented, configure on the switches to bind

the address binding of the server to the client PC.

When there are a few devices and clients, this is

a good solution. However, this solution can not

eliminate loops and broadcast storm caused by

MAC attacks.■

www.zte.com.cn

15Data Products

Malfunction Processing in VRRP and NAT Network⊙ Wan Yongfa, ZTE Corporation

Key words: VRRP, NAT, inside, outside

Network TopologyPrivate network server 1 and server 2 connect

to a 2826S switch. The 2826S switch connects to

fei_1/2 and fei_1/3 on GER_1 router and GER_2

router. The gateway of the private network server 1

is configured on fei_1/2, and that of private network

server 2 is configured on fei_1/3. VRRP is enabled

on the two routers with the two servers. The two

routers connect to DCN through fei_1/1 of their

own. NAT is configured on the two routers. When

the servers access to DCN, private addresses

are mapped into the addresses in DCN network

segment statically on the routers. The two routers

connect with each other through gei_2/2 of their

own. The topology is shown in Figure 1. Figure 1. Network Topology

May 2008 Issue 102


Malfunction SituationWhen the link from fei_1/1 of GER_1

router to DCN and the link from fei_1/2

of GER_2 router to the 2826S switch are

interrupted, the private network server 1

failed to access to DCN.

Malfunction AnalysisEngineers checked configuration on

the devices. They found that there was no

configuration on the 2826S switch. The

configuration on GER_1 is shown below:

interface fei_1/1

i p a d d r e s s 1 3 � . 6 5 . 9 3 . 2 0 1

255.255.255.0

negotiation auto

ip proxy-arp

ip nat outside

!

interface fei_1/2

i p add ress 209 .56 .132 .2�7

255.255.255.0

negotiation auto

ip proxy-arp

vrrp 1 ip 209.56.132.2�7

ip nat inside

!

interface fei_1/3

i p add ress 209 .56 .1�1 .2�7

255.255.255.0

negotiation auto

ip proxy-arp

vrrp 2 ip 209.56.1�1.2�7

ip nat inside

interface gei_2/2

i p a d d r e s s 1 9 2 . 1 6 8 . 11 . 1

255.255.255.0

negotiation auto

hybrid-attribute copper

!

!**********After interface -- show run on RP

start!**********

!

ip nat start

ip nat inside source static 209.56.132.95

13�.165.66.183

ip nat inside source static 209.56.1�1.95

13�.165.13.202

ip route 136.0.0.0 255.0.0.0 192.168.11.2

200 tag 255

ip route 136.0.0.0 255.0.0.0 13�.65.9.21

ip route 13�.0.0.0 255.0.0.0 192.168.11.2

200 tag 255

ip route 13�.0.0.0 255.0.0.0 13�.65.9.21

!

router ospf 1

router-id 192.168.11.1

network 192.168.11.0 0.0.0.255 area 0.0.0.0

network 209.56.132.0 0.0.0.255 area 0.0.0.0

network 209.56.1�1.0 0.0.0.255 area 0.0.0.0

passive-interface default

no passive-interface gei_2/2

……

The configuration on GER_2 is similar with the

configuration on GER_1.

A message from the private network server

1 reached GER_1 through fei_1/2, supposed

that the message with destination address of

13�.56.100.2 and private network source address

of 209.56.132.95. Fei_1/2 on the GER_1 router

was an inside interface of NAT. As gei_2/2 on the

GER_1 router was a common interface, the source

address was not translated into a public network

address when the message was forwarded from

gei_2/2 on the GER_1 router. When the GER_2

router received the message through gei_2/2, the

message was forwarded to DCN through fei_1/1

on the GER_2 router without the address being

translated into a public network address. Therefore,

the source address of the message was still the

www.zte.com.cn

17Data Products

private network address 209.56.132.95. Response

message could not return from DCN. Therefore,

communication failed.

SolutionTo solve the malfunction, engineers configured

the gei_2/2 interfaces on both routers to be the

outside interfaces of NAT. The configuration is

shown below:

GER_1#show running-config interface

gei_2/2

Building configuration...

!

interface gei_2/2

ip address 192.168.11.1 255.255.255.0

negotiation auto


ip nat outside

!

GER_2#show running-config interface

gei_2/2


!

interface gei_2/2

ip address 192.168.11.2 255.255.255.0

negotiation auto


ip nat outside

!

After engineers finished the configuration, a

new malfunction appeared. When the gateways of

the two servers were not on the same router, for

example, when fei_1/3 on GER_1 and fei_1/2 on

GER_2, the two servers could not communicate

with each other.

Engineers analyzed this problem. Supposed

that server 1 sent a message to server 2, with

source address 209.56.132.95 and destination

address 209.56.1�1.95. When the message

reached GER_1, it was forwarded to GER_2

through gei_2/2. The source address was

translated into 13�.165.66.183. When the

message reached gei_2/2 on GER_2, the

destination address was translated into

134.165.13.202. GER_2 could not forward

the message to server 2 according to

the destination address. Therefore, the

communication between the two servers

failed.

To solve the problem, engineers

configured the gei_2/2 interfaces on both

routers to be the inside interfaces of NAT.

The configuration is shown below:

GER_1#show runn ing-conf ig

interface gei_2/2


!

interface gei_2/2

i p a d d r e s s 1 9 2 . 1 6 8 . 11 . 1

255.255.255.0

negotiation auto


ip nat inside

!

GER_2#show runn ing-conf ig

interface gei_2/2


!

interface gei_2/2

i p a d d r e s s 1 9 2 . 1 6 8 . 11 . 2

255.255.255.0

negotiation auto


ip nat inside

!

Experience SummaryWhen messages are forwarded by

more than two routers that enable NAT,

the inside interfaces and outside interfaces

of NAT should be configured correctly. ■

May 2008 Issue 102


Malfunction on MPLS VPN Service⊙ Dai Jun, ZTE Corporation

Key words: MPLS VPN, MTU, T128, GE, transmission

Network TopologyIn a network, ZXR10 T128 routers work

as P devices in the core layer, and ZXR10

T6�E/T6�G routers work as PE devices in the

aggregation layer. MPLS VPN is configured in this

network. The two T128 routers connect with each

other through GE interfaces. T128-1 connects with

T6�G-2 through GE interfaces. T128-2 connects

with T6�E-1 through GE interface. T128-1 connects

with T6�G-1 and T6�G-3 through transmission link

GE. The network topology is shown in Figure 1.

Malfunction Situation

Users in the MPLS-VPN network could ping

to the application server successfully. When they

accessed to the application server, some services

were normal, and some services were abnormal.

For these abnormal services, the system prompted

that connections to the database were abnormal.

Malfunction AnalysisAccording to the working principle of MPLS-Figure 1. Network Topology

www.zte.com.cn

19Data Products

VPN, malfunctions in MPLS-VPN services can be

processed in the following steps.

1. Use show mpls forwarding-table command

to check whether the P devices and PE devices

generate label forwarding tables correctly.

2. Use show ip rou te v r f <v r f name>

command to check whether VPN routes are

generated correctly in the VPN routing tables.

3. Check the MTU values of Ethernet

interfaces on the devices. For double labels, the

MTU value of an Ethernet interface should be at

least 1526 bytes. As the length of an Ethernet

II frame can be 1518 at most, after the frame is

encapsulated by double labels, the length of the

frame can be 1526 (1518+�+�) bytes.

In the malfunction situation, users could ping to

the application server successfully. This indicated

that the label forwarding tables and VPN routing

tables were generated correctly. For the problem

that some services were normal and some services

were abnormal, this might be caused by the

transmission links.

SolutionTo solve the problem, engineers took the

following steps.

1. Engineers checked the clients. They found

that there was no problem and all services ran

normally. There was no prompt that connections to

the database were abnormal.

2. Engineers made tests at client-1. They

found that there was no problem. Engineers made

tests at client-2. They found that some services

were normal and some services were abnormal,

and there were prompts that connections to the

database were abnormal.

3. Engineers pinged to the application

server on T6�G-3. They found that only messages

of length within 1�96 bytes could get through.

Engineers logged into T6�G-2, and they pinged

the application server on T6�G-2. They found that

messages of different lengths could get through.

Engineers compared T6�G-2 with T6�G-3.

They found that T6�G-2 connected to

T128-1 through GE interface directly, while

T6�G-3 connected to T128-1 through

transmission GE link. Therefore, the

problem might be on the device.

�. Engineers checked the MTU

values of GE optical interfaces on the

devices. They found that the MTU values

were 1522 bytes, while the length of a

frame could be 1526 bytes after double

labe l encapsu la t ion in MPLS-VPN

services. Therefore, engineers changed

the MTU values to 1526 bytes of GE

optical GE interfaces.

Af ter changing the MTU values,

engineers made tests. All services were

normal. The problem was solved.

Experience SummaryFor MPLS-VPN services, make sure

about the configuration to obtain label

forwarding tables and VPN routing tables

correctly.

In the MPLS-VPN network, there are

multiple kinds of transmission devices.

D i f fe ren t MTU va lues on Ethernet

interfaces may cause MPLS-VPN service

abnormality. For MPLS-VPN services, the

MTU values on Ethernet interface should

be at least 1526 bytes to forward frames

with double labels correctly. ■

May 2008 Issue 102


Malfunction on Uplinks⊙ Liang Yongfeng, Guangdong Filiale of China Telecom

Key words: ZXR10 3228, ZTE 9210, loop, address drifting

Network TopologyStudents get online through a ZTE

9210 in the dormitories. The network

topology is shown in Figure 1. The ZXR10

3228 switch replaces a Cisco 3750 switch.

The direction of data packets is: ZTE 9210

(interfaces 16/1 and 16/2) → the two 100M

uplinks → Cisco 3570 → ZXR10 T64G-1

→ Jinxia MA5200G (BRAS).


This was a network topology of a

university. Due to network change, a Cisco

3750 switch was replaced by a ZXR10

3228 switch of ZTE. Related configuration

was configured on the ZXR10 3228

switch. The two uplinks from a ZTE 9210

connected to the ZXR10 3228 switch. After Figure 1. Network Topology

www.zte.com.cn

21Data Products

that, there were alarms about of address drifting appearing on the ZXR10 3228 switch, as shown

below:

An alarm 22789 level 6 occurred at 16:23:02 01/28/2008 UTC sent by MCP %MAC% <

MAC Table> <MAC 0018.B9D3.7E9B VLAN 1> From Port fei_1/9 To Port fei_1/7








MAC Table> <MAC 0018.B9DF.8D9B VLAN 1> From Port fei_1/9 To Port gei_2/1


MAC Table> <MAC 0018.B9DF.8D9B VLAN 1> From Port gei_2/1 To Port fei_1/7

When the uplinks were cut off, the alarms disappeared.

Malfunction AnalysisBefore the Cisco 3750 switch was replaced by the ZXR10 3228 switch, there was no such

alarm. As the network topology was not changed too much, the direction of data packets was: ZTE

9210 (interfaces 16/1 and 16/2) → the two 100M uplinks → ZXR10 3228 → ZXR10 T64G-1 →

Jinxia MA5200G (BRAS).

To find out the problem, engineers took the following steps.

1. Engineers checked the state of the interface that connected to the ZTE 9210 on the

ZXR10 3228 switch, as shown below:

QY_daxuecheng_3228#show run interface fei_1/5


interface fei_1/5

description qy_daxuecheng9210_adsl-16-1

no negotiation auto

switchport mode trunk

switchport trunk native vlan 1

switchport trunk vlan 29


switchport qinq normal

QY_daxuecheng_3228#show run interface fei_1/7


interface fei_1/7

description to daxuecheng9210-16-2

no negotiation auto

May 2008 Issue 102


switchport mode trunk

switchport trunk native vlan 1



switchport qinq normal

The result indicated that there was no

problem.

2. Engineers checked the state of

the interface that connected to the ZXR10

3228 switch on the ZTE 9210, as shown

below:

daxuecheng2#show interface 16/1

Interface : 16/1

name : default

pvid : 1

AdminStatus : enable

LinkStatus(Eth) : up

ifType : ethernet-csmacd

Auto Negotiate : disable

DuplexSpeed : full-100M

ifMtu : 1500

CosPriority : level 0

Trap : disable

Flow-control : force-disable

IngressFilter : accept

AcceptFrame : admitall

Fast-leave : enable

Group Limit : 512

Group Band : 10�8576 Kbps

daxuecheng2#show interface 16/2

Interface : 16/2

name : default

pvid : 1

AdminStatus : enable

LinkStatus(Eth) : up

ifType : ethernet-csmacd

Auto Negotiate : disable

DuplexSpeed : full-100M

ifMtu : 1500

CosPriority : level 0

Trap : disable

Flow-control : force-disable

IngressFilter : accept

AcceptFrame : admitall

Fast-leave : enable

Group Limit : 512

Group Band : 10�8576 Kbps

The result indicated that there was no problem.

3. As the alarms appeared on the interfaces

connecting to the uplinks from the ZTE 9210

to the 3228 switch, engineers implemented

troubleshooting on the ZTE 9210 and the ZXR10

3228 switch according to MAC address learning.

�. Engineers cut off the two uplinks, and then

the alarms disappeared. When one of the uplinks

was recovered, the alarms appeared again. This

might be caused by the MAC addresses that were

not timed out on the uplink interfaces of the ZTE

9210.

5. As the alarms were mainly for VLAN 1,

engineers changed the Native Vlan on one of the

downlink interfaces on the ZXR10 3228 switch.

Engineers changed the Native Vlan to VLAN 29,

and then the alarms appeared, as shown below:

An alarm 22789 level 6 occurred at 16:�0:21

01/28/2008 UTC sent by MCP %MAC% <

MAC Table> <MAC 0018.B9DF.7F9B VLAN

29> From Port gei_2/1 To Port fei_1/9

An alarm 22789 level 6 occurred at

16:�0:22 01/28/2008 UTC sent by MCP

%MAC% <

MAC Table> <MAC 0018.B9DF.8D9B VLAN

29> From Port fei_1/9 To Port gei_2/1

6. Engineers checked the configuration on

the ZTE 9210. They found that the PVID of both

uplink interfaces on the ZTE 9210 were the default

www.zte.com.cn

23Data Products

values VLAN 1, and the Native Vlan values were also default values. This might be the reason of

the problem.

7. Engineers checked the MAC address learning information of the two uplink interfaces on

the ZTE 9210, as shown below:

daxuecheng2#show fd 16/1

The mac address number of the port 16/1 is 10

slot/port MAC ADDRESS VLANID

16/1 00:0f:e2:50:c5:10 29

16/1 00:d0:d0:92:01:13 29

16/1 00:e0:fc:af:�9:33 588

16/1 00:d0:d0:c1:1d:20 1

16/1 00:d0:d0:92:02:20 29

16/1 00:d0:d0:92:02:23 29

16/1 00:d0:d0:92:0�:30 29

16/1 00:d0:d0:92:01:�7 29

16/1 00:d0:d0:92:0�:88 29

16/1 00:18:b9:df:7f:9b 1



The mac address number of the port 16/2 is 1�


16/2 00:0b:5f:f�:11:18 1

16/2 00:d0:d0:c1:1d:20 1

16/2 00:e0:fc:af:�9:33 385

16/2 00:�0:05:11:6a:73 851

16/2 00:0d:bd:3d:27:6f 1

16/2 00:0f:e2:10:a2:�� 851

16/2 00:19:e0:02:f8:b� 851

16/2 00:15:e9:�7:e1:bb 851

16/2 00:18:b9:d3:7e:9b 1

16/2 00:18:b9:df:7f:9b 1

16/2 00:18:b9:df:8d:9b 1

The mac address number of the port 16/2 is 1�

The result indicated that the two uplink interfaces learned multiple same MAC addresses.

8. Engineers changed the PVID values of the two uplink interfaces into the values that were

not used in this network, for example, PVID of fei_16/1 was changed into 4092, and PVID of

fei_16/2 was changed into 4093. After that, the alarms disappeared. Engineers checked the MAC

address learning information again, as shown below:

May 2008 Issue 102





16/1 00:d0:d0:92:05:00 29

16/1 00:0f:e2:50:c5:10 29

16/1 00:d0:d0:92:01:13 29

16/1 00:e0:fc:af:�9:33 588

16/1 00:d0:d0:92:02:20 29

16/1 00:d0:d0:92:02:23 29

16/1 00:d0:d0:92:01:�7 29

16/1 00:d0:d0:92:0�:99 29

16/1 00:18:b9:df:7f:9b 29





16/2 00:e0:fc:af:�9:33 385

16/2 00:0f:e2:10:a2:�� 851

16/2 00:19:e0:02:f8:b� 851

16/2 00:15:e9:�7:e1:bb 851

16/2 00:e0:b0:f0:33:8c 851

16/2 08:10:17:01:�3:d6 851

16/2 00:13:20:97:af:d1 851


The result indicated that the two interfaces did not learn the same MAC address from the same

VLAN.

9. Engineers checked the MAC addresses that appeared in the alarms. They found that

the MAC addresses were the addresses of uplink interfaces on the Liangwei 3750-1 switch, for

example, 0018.b9df.7f9b was the address of GE interface on the switch.

10. Engineers checked the configuration on the ZXR10 T6�G-1 switch and the Liangwei

3750-1 switch. They found that spanning-tree function was disabled on ZTE switches, and the

interfaces on ZTE switches were without MAC addresses; while spanning-tree function was

enabled on Cisco switches, and the interfaces on Cisco switches were with MAC addresses.

11. Engineers checked the information about 0018.b9df.7f9b on the ZXR10 T6�G-1 switch,

as shown below:

YanJiangT64G#show mac 0018.b9df.7f9b

Total MAC address : 7

MAC_Address port vid stc per toS srF dsF Frm vpn inner Time

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

www.zte.com.cn

25Data Products

0018.b9df.7f9b gei_4/12 53 0 0 0 0 0 0 0 0 5:11:46:42

0018.b9df.7f9b gei_4/12 3115 0 0 0 0 0 0 0 0 5:11:46:42

0018.b9df.7f9b gei_4/12 29 0 0 0 0 0 0 0 0 5:11:51:41

0018.b9df.7f9b gei_4/12 3114 0 0 0 0 0 0 0 0 5:11:46:41

0018.b9df.7f9b gei_4/12 747 0 0 0 0 0 0 0 0 5:11:46:42

0018.b9df.7f9b gei_4/12 1 0 0 0 0 0 0 0 0 5:11:46:44

0018.b9df.7f9b gei_4/12 30 0 0 0 0 0 0 0 0 5:11:46:41

Engineers checked the information about 0018.b9df.7f9b on the ZXR10 3228 switch, as shown

below:

QY_daxuecheng_3228#show spanning-tree statistics gei_2/1

%Code 11201:Error: Spanning-tree Protocol is disabled!

QY_daxuecheng_3228#show mac 0018.b9df.7f9b


MAC_Address port vid stc per toS srF dsF Time

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

0018.b9df.7f9b gei_2/1 1 0 0 0 0 0 5:13:43:44

0018.b9df.7f9b gei_2/1 29 0 0 0 0 0 5:13:43:43

Engineers checked the information about 0018.b9df.7f9b on the Liangwei 3750-1 switch, as

shown below:

QY_LiangWei_3750#show interface gi1/1/1

GigabitEthernet1/1/1 is up, line protocol is up (connected)

Hardware is Gigabit Ethernet, address is 0018.b9df.7f9b (bia 0018.b9df.7f9b)

Description: QY_YJ_T64G_G4/12

QY_LiangWei_3750#show spanning-tree vlan 29

VLAN0029

Spanning tree enabled protocol ieee

Root ID Priority 32797

Address 0018.b9df.7f80

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32797 (priority 32768 sys-id-ext 29)

Address 0018.b9df.7f80

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

May 2008 Issue 102


Interface Role Sts Cost Prio.Nbr Type

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

Fa1/0/8 Desg FWD 19 128.10 P2p

Fa1/0/9 Desg FWD 19 128.11 P2p

Gi1/1/1 Desg FWD � 128.27 P2p

According to the above results, spanning-tree function was enabled on the Liangwei 3750

switch, and the uplink interface had a MAC address. Therefore, the Tanjiang T6�G-1 switch

learned the MAC addresses of VLAN on the Liangwei 3750 switch, and the MAC addresses

of different VID values were all MAC addresses on GE interfaces of the Liangwei 3750 switch.

Uplink GE interfaces on the ZXR10 3228 switch also learned the MAC address corresponding to

VID value. This MAC address was forwarded to the uplink interfaces of the ZTE 9210. The PVID

values on the two uplink interfaces were 1, which led to a loop, so alarms for MAC address drifting

appeared.

Before the ZXR10 3228 switch replaced the Cisco 3750 switch, spanning-tree function was

enabled on the Cisco 3750 switch. Therefore, there was no loop and alarm.

SolutionTo solve the problem, engineers took the following steps.

1. Change the PVID values of uplink interfaces on the ZTE 9210 into the values that have

not been used in this network.

2. Change the Native Vlan values of the downlink interfaces on the ZXR10 3228 switch into

the values that have not been used in this network.

3. Disable the spanning-tree function on the Cisco 3750-1 switch.

Experience SummaryBefore connecting ZTE switches with switches of other vendors, check the state of spanning-

tree function on the devices. To enable or disable the function, it is up to the network topology.■

www.zte.com.cn

27Data Products

Malfunction in Cluster Management⊙ Liu Aixin, ZTE Corporation

Key words: 2818S, cluster management, version upgrade, ztp

Network TopologyAs shown in Figure 1, the ZXR10 3206 switch

works as a command switch in the cluster, and

the three ZXR10 2818S switches work as member

switches in the cluster.

switches ZXR10 2818S were down when

users viewed the information through

the command switch ZXR10 3206. To

solve the problem, it was required to

delete primary configuration about cluster

management on all member switches, and

then add the members to the cluster on

the command switch again. As member

located in di fferent stat ions, i t was

impossible to do it.

SolutionTo solve the problem, engineers took

the following steps.

1. Engineers configured a new VLAN

management interface for the command

switch and member switches. Therefore,

engineers could log into the command

switch or member switches through

another network segment, for example,

10.10.10.0/2�.

Malfunction SituationAn enterprise used many ZXR10 2818S

switches of 1.0 version. After theses switches were

upgraded to 1.1.11 version, the states of member


May 2008 Issue 102


2. Engineers configured a new network segment for IP addresses on the command switch,

as shown below:

zte3206#config terminal

zte3206(config)#vlan 2

zte3206(config-vlan)#exit

zte3206(config)#interface vlan 2

zte3206(config-if)#ip address 10.10.10.1 255.255.255.0

zte3206(config-if)#exit

zte3206(config)#interface fei_1/2

//the interface connecting to 2818S on 3206

zte3206(config-if)#swichport trunk vlan 2

zte3206(config-if)#exit

3. Engineers configured a new network segment for IP addresses on each member switch,

as shown below. The configuration should be saved.

zte2818(cfg)#set vlan 2 enable

zte2818(cfg)#set vlan 2 add port 17 tag

zte2818(cfg)#config router

zte2818(cfg-router)#set ipport 1 vlan 2

zte2818(cfg-router)#set ipport 1 ipaddress 10.10.10.2 255.255.255.0

zte2818(cfg-router)#set ipport 1 enable

zte2818(cfg-router)#exit

zte2818(cfg)#save

�. Engineers logged into a member switch through the new VLAN management interface,

and then deleted the IP address that was assigned by the command switch before version

upgrade. An example is shown below:

zte2818(cfg)#config router

zte2818(cfg-router)#set ipport 0 disable

zte2818(cfg-router)#clear ipport 0

zte2818(cfg-router)#exit

5. Engineers input no group member command on the command switch to delete the old

member switches, as shown below:

zte3206(config)#no group member

6. Engineers input ztp start command on the command switch to obtain the new topology, as

shown below:

www.zte.com.cn

29Data Products

zte3206(config)#ztp start

7. Engineers input show ztp device-list command on the command switch to view information

about the member switches.

zte3206#show ztp device-list

Index DeviceID MacAddress Hop SwitchType Platform

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

1 1 00d0.d0c2.c224 1 MEMBER_SWITCH ZXR10 2818S

2 2 00d0.d0fc.76f2 1 MEMBER_SWITCH ZXR10 2818S

3 3 00d0.d0fc.7673 1 MEMBER_SWITCH ZXR10 2818S

4 0 00d0.d0c6.5582 0 COMMAND_SWITCH ZXR10 3206

8. Engineer input group member device <device-id> command on the command switch to

add the member switches again.

zte3206(config)#group member device 1

zte3206(config)#group member device 2

zte3206(config)#exit

9. Engineers input show group member command to view the information about the member

switches again. The result showed that the member switches were added correctly, and the states

were UP, as shown below:

zte3206#show group members

Index MemberID MacAddress IpAddress Mask Status

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

1 1 00d0.d0c6.5582 192.168.1.1 255.255.255.0 Up

2 2 00d0.d0c2.c22� 192.168.1.2 255.255.255.0 Up

3 3 00d0.d0fc.76f2 192.168.1.3 255.255.255.0 Up

� � 00d0.d0fc.7673 192.168.1.� 255.255.255.0 Up

zte3206#group save-member all

Engineers saved all configurations and the problem was solved.■

May 2008 Issue 102


3952 Connecting to MSG9000 GEB⊙ Feng Chao, ZTE Corporation

Key words: ICMP, UDP, MSG9000, debug

Network TopologyThe IP address of a board on a MSG

9000 is 10.1.0.5/30. The board connects

to gei_2/1 on a ZXR10 3952 through a GE

optical interface. The IP address of an SS

is 10.0.0.1/24. The SS connects to fei_1/4

on the ZXR10 3952. The IP addresses of

VLAN 100 and VLAN 200 are 10.1.0.6/30

and 10.0.0.25�/2�. The network topology

is shown in Figure 1.


1. Users could ping to the address

10.1.0.5 on the MSG 9000 and the

address 10.0.0.1 on the SS successfully.

2. Users could detect the address

10.1.0 .5 o f the board on the MSG

9000 through the background network

management system of SS. The state was

alive.

3. Users could detect the gateway

address 10.1.0.6 of the MSG 9000 through

the background network management

system of MSG9000. The state was

alive. However, users failed to detect the gateway

address 10.0.0.25�/2� of the SS on the 3952

switch and the board address 10.0.0.1 on the SS.

The states were unreachable.

Malfunction Analysis1. According to malfunction, the configuration

on the 3952 switch, the configuration of IP

addresses for the SS, the MSG9000 and the

network management system were normal.

Engineers logged into the 3952 switch, and they

found there was no problem about CPU utilization

rate, ARP table and routing table.

2. Engineers input debug ip icmp command

on the 3952 switch, and then enabled detection

function with destination address 10.0.0.25� on the

MSG9000. Debug information on the 3952 switch

is shown below:


www.zte.com.cn

31Data Products

�d9h IP ICMP:sent type dest unreachable,

code 0, src 10.0.0.25�, dst 10.0.0.12


code 0, src 10.0.0.25�, dst 10.0.0.12


code 3, src 10.1.0.6, dst 10.1.0.5


code 0, src 10.0.0.25�, dst 10.0.0.12

……

Debug information appeared immediately, which

indicated that there were packets sent to the 3952

switch when engineers enabled detection function

on the MSG 9000. The packets also triggered the

3952 switch to send two kinds of ICMP response

messages. In normal situation, if the 3952 switch

receives ICMP messages, the system will prompt

information of rsv ICMP messages when engineers

input debug ip icmp command. In the above result,

there was not any prompt information. Therefore,

engineers considered that the MSG9000 did not

send ICMP request messages to the 3952 switch.

3. Engineers enabled port mirroring function

on the GE interface of the 3952 switch that

connected to the MSG9000, and then engineers

enabled address detection function to detect the

destination 10.0.0.25�. With the Sniffer tool, the

result is shown in Figure 2.

The result showed that the MSG9000 sent a

UDP message with destination port number 1001.

When the 3952 switch received the message,

it responded with a type 3 ICMP message (Port

destination unreachable). In normal situation, when

a host tries to connect to a port number (less than

102�) that does not exist on the peer device, the

peer should respond with ICMP messages with

type 3 and code 3.

�. Engineers enabled address detection

function to detect the destination 10.1.0.6. With the

Sniffer tool, the result is shown in Figure 3.

The result showed that the MSG9000 sent a

normal ICMP request messages with source address 10.1.0.5

and destination address 10.1.0.6. When the 3952 switch received

the message, it responded with a normal ICMP reply message

with source address 10.1.0.6 and destination address 10.1.0.5.

According to the analysis, engineers found out the problem.

The malfunction was caused by the detection mechanism on the

MSG9000. It was about the program or version of the device.

When the detected address and the address of the line card

of MSG 9000 were in the same network segment, MSG 9000

sent normal ICMP messages. Otherwise, MSG 9000 sent UDP

messages with destination of gateway.

Experience SummaryWhen such malfunctions appear, pay attention to the

detection messages. The detection messages may not be ICMP

messages. To implement troubleshooting, users can use debug

commands and Sniffer tool. ■

Figure 2. The Result of packet capturing 1

Figure 3. The result of packet capturing 2

May 2008 Issue 102


IP Prefix-List Configuration⊙ Zhu Xuan, ZTE Corporation

Key word: ip prefix-list

Malfunction SituationOn a router, there were more than ten

ip prefix-lists configured. Users wanted to

configure more ip prefix-lists. When they

deleted a seq of one prefix-l ist, system

prompted error information, as shown below:

ZXR10(config)#no ip prefix-list zte seq

5 permit 10.1.1.0 2�

ZXR10(config)#ip prefix-list zte seq 20

per 50.1.1.0 2�

%Code 289: prefix-list write error.

SolutionFor a router that is with more than ten ip

prefix-lists, it is not allowed to delete the seq of

one prefix-list and then configure a new seq.

The error information “%Code 289: prefix-

list write error” means that the system fails to

write the prefix-list to the database.

Supposed that there have been ten prefix-

lists on a router. The ip prefix-list zte is the

eleventh prefix-list. The contents of this prefix-

list is shown below:

ZXR10(config)#sho ip prefix-list zte

Prefix-list with the last deletion/insertion:

zte

ip prefix-list zte 2 entries

seq 5 permit 10.1.1.0/2�

seq 10 permit 20.1.1.0/2�

To configure a new prefix-list, there are two

methods, as shown below.

One method is to configure new seqs in ip

prefix-list zte, as shown below:

ZXR10(config)#ip prefix-list zte permit

30.1.1.0 2�

ZXR10(config)#show ip prefix-list zte

Prefix-list with the last deletion/insertion: zte

ip prefix-list zte 3 entries

seq 5 permit 10.1.1.0/2�

seq 10 permit 20.1.1.0/2�

seq 15 permit 30.1.1.0/2�

The other method is to delete the ip prefix-list

zte, and configure a new list and its seqs, as shown

below:

ZXR10(config)#no ip prefix-list zte

ZXR10(config)#ip prefix-list zte permit

1.1.1.0 2�

//the name of the list can be defined by

users, here it is zte

ZXR10 (config)#ip prefix-list zte permit

2.1.1.0 2�

Experience SummaryFor a router that is with more than ten ip prefix-

lists, do not delete the seq of one prefix-list and

then configure a new seq. Otherwise, system will

prompt error information of No.289. ■

www.zte.com.cn

33Data Products

STP malfunction on 2826S Switch⊙ Li Weiting, ZTE Corporation

Key words: STP, VRRP, Mac address, management address

Network TopologyAs shown in Figure 1, the three devices form a

loop. Spanning-tree function is enabled on these

three devices. A smartgroup is configured between

switches 3906-1 and 3906-2. Switches 3906-1 and

3906-2 run VRRP, and switch 3901-1 is the master.


Users could ping to the management address

of switch 2826S on switch 3901-1 successfully, but

they could not ping to the same address on switch

3906-2. Figure 1. Network Topology

Malfunction Analysis1. Engineers checked the information of spanning-tree instances on the three switches.

The information of spanning-tree instances on switch 3906-1 is shown below:

3906-1#show spanning-tree instance 0

Spanning tree enabled protocol MSTP

Root ID: Priority �096; Address 00d0.d0c0.03c0

Hello-Time 2 sec; Max-Age 20 sec

Forward-Delay 15 sec;

RegRootID: Priority �096; Address 00d0.d0c0.03c0

BridgeID: Priority �096; Address 00d0.d0c0.03c0


Forward-Delay 15 sec; Max-Hops 20

Message-Age 0 sec; RemainHops 20

Interface Prio.Nbr

Name Port ID Cost Sts Role Type Bound

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

fei_1/8 128.48 200000 Forward Designated p2p MSTP

sg1 128.1 100000 Forward Designated p2p MSTP

May 2008 Issue 102


The information of spanning-tree instances on switch 3906-2 is shown below:

3906-2#show spanning-tree instance 0

Spanning tree enabled protocol MSTP

Root ID: Priority �096; Address 00d0.d0c0.03c0


Forward-Delay 15 sec;

RegRootID: Priority 8192; Address 00d0.d0c0.0280

BridgeID: Priority 8192; Address 00d0.d0c0.0280


Forward-Delay 15 sec; Max-Hops 20

Message-Age 1 sec; RemainHops 20

Interface Prio.Nbr

Name Port ID Cost Sts Role Type Bound

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

fei_1/8 128.48 200000 Forward Designated p2p MSTP

sg1 128.1 100000 Forward Root p2p MSTP

The information of spanning-tree instances on switch 2826S is shown below:

2826S(cfg)#show stp instance 0

RootID:

Priority : �096 Address : 00.d0.d0.c0.03.c0

HelloTime(s) : 2 MaxAge(s) : 20

ForwardDelay(s): 15

Reg RootID:

Priority : 1638� Address : 00.d0.d0.fc.76.92

RemainHops : 20

BridgeID:

Priority : 1638� Address : 00.d0.d0.fc.76.92

HelloTime(s) : 2 MaxAge(s) : 20

ForwardDelay(s): 15 MaxHops : 20

Interface PortId Cost Status Role Bound GuardStatus

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

1 128.1 200000 Forward Root MSTP None

2 128.2 200000 Discard Alternate MSTP None

www.zte.com.cn

35Data Products

The above results showed that switch 3906-1 had the highest priority, and it worded as the

root switch. The state of port 2 on switch 2826S is Discard, which indicated that the link between

switches 3906-2 and 2826S was blocked.

2. The management address of switch 2826S was 192.168.69.132. Engineers ping to the

address on switch 3906-2, as shown below:

3906-2#ping 192.168.69.132

sending 5,100-byte ICMP echos to 192.168.69.132,timeout is 2 seconds.

……

3. Engineers checked ARP on switch 3906-2, as shown below:

3906-2#show arp

Arp protect whole is disabled . The count is 3.

Address Age(min) Hardware Addr Interface

192.168.69.132 2 00d0.d0fc.7692 vlan601

192.168.70.2 - 00d0.d0c0.0283 vlan601

192.168.69.130 - 00d0.d0c0.0283 vlan601

�. Engineers check the MAC address table on switch 3906-2, as shown below:

3906-2#show mac dynamic

Total MAC address : �

Flags: vid --VLAN id, stc --static

per --permanent, toS --to-static

srF --source filter, dsF --destination filter

time --day:hour:min:sec


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

00d0.d0fc.7692 fei_1/8 601 0 0 0 0 0 0:01:32:56

0000.5e00.011� sg1 601 0 0 0 0 0 0:01:33:15

0000.5e00.011e sg1 601 0 0 0 0 0 0:01:33:15

00d0.d0c0.03c0 sg1 601 0 0 0 0 0 0:01:33:18

The above result showed that the MAC address 00d0.d0fc.7692 was learned on fei_1/8

of switch 3906-2. In spanning-tree protocol, switches interact to each other through BPDU

messages. BPDU messages are transmitted in the format of Ethernet frames. The source MAC

address of a BPDU message is the MAC address of the switch that sends the BPDU message.

Although the state of fei_1/2 on switch 2826S was Discard, BPDU messages were not affected.

Therefore, switch 3906-2 learned the MAC address 00d0.d0fc.7692 through the BPDU message

that was sent by switch 2826S.

May 2008 Issue 102


SolutionTo solve the problem, engineers changed the MAC address of network management system

on switch 2826S into an address that was different from that of the switch itself, as shown below:

2826S(cfg)#config router

2826S(cfg-router)#set ipport 0 disable

2826S(cfg-router)#set ipport 0 mac 00.D0.D0.FC.76.76

Engineers checked the information of ARP and MAC, as shown below:

3906-2#show arp

Arp protect whole is disabled . The count is 3.

Address Age(min) Hardware Addr Interface

192.168.69.132 0 00d0.d0fc.7676 vlan601

192.168.70.2 - 00d0.d0c0.0283 vlan601

192.168.69.130 - 00d0.d0c0.0283 vlan601

3906-2#show mac dynamic


Flags: vid --VLAN id, stc --static

per --permanent, toS --to-static

srF --source filter, dsF --destination filter

time --day:hour:min:sec


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

00d0.d0fc.7676 sg1 601 0 0 0 0 0 0:00:�1:52

00d0.d0fc.7692 fei_1/8 601 0 0 0 0 0 0:00:45:15

0000.5e00.011e sg1 601 0 0 0 0 0 0:00:�3:30

0000.5e00.011� sg1 601 0 0 0 0 0 0:00:�3:30

00d0.d0c0.03c0 sg1 1 0 0 0 0 0 0:00:�3:31

The above result showed that the MAC address corresponding to the network management

address 192.168.69.132 on switch 2826S was 00d0.d0fc.7676. Switch 3906-2 learned this MAC

address through sg1. Therefore, messages passed by switch 3906-1 and then reached switch

2826S. The problem was solved. ■

www.zte.com.cn

37Data Products

May 2008 Issue 102


preface - ztezte.by/magazine/maintenance experience, issue102(data products).pdf · deputy...

Documents