Maintenance Experience Issue219 (Data Products) PDF

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 contents presented in this issue are twelve maintenance
cases of ZTE's data products.
Have you examined your service polices and procedures
lately? Are you confident that your people are using all the
tools at their disposal? Are they trained to analyze each
issue in a logical manner that provides for less downtime and
maximum customer service? A close look at the cases reveals
how to isolate suspected faulty or mis-configured equipment,
and how to solve a problem step by step, etc. As success in
commissioning and service is usually a mix of both discovery
and analysis, we consider using this type of approach as an
example of successful troubleshooting investigations.
While corporate leaders maintain and grow plans for
expansion, ZTE employees in all regions carry out with individual
efforts towards internationalization of the company. Momentum
continues to be built, in all levels, from office interns to veteran
engineers, who work together to bring global focus into their
daily work.
If you would like to subscribe to this magazine (electronic
version) or review additional articles and relevant technical
materials concerning ZTE products, please visit the technical
support website of ZTE CORPORATION (http://ensupport.zte.
com.cn).
If you have any ideas and suggestions or want to offer your
contributions, you can contact us at any time via the following
email: doc@zte.com.cn.
Thank you for making ZTE a part of your telecom experience!
Maintenance Experience
Bimonthly for Data Products
No.17 Issue 219, June 2010
Editorial Committee
Director: Qiu Weizhao
Deputy Director: Chen Jianzhou
Editors:
Fang Xi, Wang Zhaozheng, Xu Xinyong,
Xiao Shuqing, Zhang Jian, Zhang Jiebin,
Zhou Guifeng, Zhao Cen, Zhao Haitao, Jiang
Haijun, Xu Zhijun, Huang Ying, Ge Jun, Dong
Yemin, Dong Wenbin
Technical Senior Editors:
Hu Jia, Tao Minjuan, Zhang Jianping
Executive Editor:
Zhang Fan
Newsroom
Address: ZTE Plaza, No.55, Hi-tech Road
Maintenance Experience Editorial Committee

ZTE CORPORATION
June, 2010
South, Shenzhen, P.R.China

Postal code: 518057
Contact: Ning Jiating
Email: doc@zte.com.cn
Tel: +86-755-26771195
Fax: +86-755-26772236
Document support mail box: doc@zte.com.cn
Technical support website: http://ensupport.zte.
com.cn
Contents
LACP Configuration on ZXR10 8902 Switch.............................................................................................. 2

Sporadic Internet Access Failure................................................................................................................ 4
Experience About POS Interface Interconnection...................................................................................... 6
VRRP Changeover Failure......................................................................................................................... 9
Attentions for Configuring Out-of-Band and In-Band NM on UAS................................................................11
High CUP Usage Caused by Route Loop..................................................................................................14
Service Interruption after Capability Extension..........................................................................................17
Attention for MPLS Label Configuration.....................................................................................................19
Website Access Failure in MPLS VPN.......................................................................................................20
Access Failure Caused by MRU................................................................................................................23
VPLS Service Failure on T160G................................................................................................................25
Experiences About Flow Mirroring Configuration on ZXUAS 10800..........................................................27
June 2010
Issue 219
LACP Configuration on ZXR10 8902 Switch

Ma Xuetao / ZTE Corporation
Key words: ZXR10 8902, LACP, SmartGroup, active
LACP Principle
IEEE 802.3ad-based Link Aggregation
Control Protocol (LACP) is a protocol for
dynamic aggregation of links. LACP uses
Link Aggregation Control Protocol Data
Units (LACPDUs) to interact with peer
devices.
When LACP is enabled on an
interface, the interface will send
interface in a dynamic aggregation group.
Configuration Description
A ZXR10 8902 switch interconnects with its
peer device through the optical interface gei_1/23.
Th i s o p ti c a l i n te r fa c e i s i n V L A N 2 0 0 a n d
SmartGroup 1.
The LACP mode is in Active mode (it is
system MAC address, interface priority,
necessary to negotiate this parameter with the
port number and operation key. When
peer).
device compares the information with

the information that is saved on other
interfaces to select the interfaces that
make an agreement on the joining or leaving of an
LACPDUs to advertise its system priority,
r e c e i v i n g t h e i n f o r m a t ion, the peer
can be aggregated. In this way, both devices can
Configuration Procedure
1. C r e a t e S m a r t G r o u p 1 a n d e n t e r
SmartGroup 1 configuration mode.
www.zte.com.cn
ZXR10-8902(config)#interface smartgroup1
ZXR10-8902(config-smartgroup1)#
2. Set the SmartGroup working mode to 802.3ad (LACP).

ZXR10-8902(config-smartgroup1)#smartgroup mode 802.3ad
3. Create the VLAN 200.

ZXR10-8902(config)#vlan200
4. Enter interface gei_1/23 and set the mode of this interface to Trunk.
ZXR10-8902(config)#interface gei_1/23
ZXR10-8902(config-gei_1/23)#switchport mode trunk
ZXR10-8902(config-gei_1/23)#switchport trunk vlan 200
5. Add the interface gei_1/23 to SmartGroup 1, and set the working mode to Active (it is
necessary to negotiate this parameter with the peer).
ZXR10-8902(config-gei_1/23)#smartgroup 1 mode active
After the configuration, users can view the interface state and LACP
state.
The configuration information on gei_1/23 is shown below.

ZXR10-8902(config)#show run interface gei_1/23
Building configuration
!
interface gei_1/23
out_index 25
hybrid-attribute fiber
negotiation auto
switchport mode trunk
switchport trunk vlan 200

switchport qinq normal
!
smartgroup 1 mode active
end
The LACP state is shown below.

ZXR10-8902(config)#show lacp 1 internal
Smartgroup:1
Flag *--LOOP is TRUE

Inter Interval
Actor
Port
Agg
State
Pri priority
Port
Inter
Port
Pri
Oper
Key
Port
State
RX
Machine
Mux
Machine
------------------------------------------------------------------gei_1/23
active
30
32768
0x111
0x3d
current
distributing
Data Products
June 2010
Issue 219
Sporadic Internet Access Failure

Qu Zhihui / ZTE Corporation
Key words: UAS 10600, address pool, route, VBUI
Malfunction Situation
The network topology of CNC in a city
The network phenomena are described as

follows:
is shown in Figure 1. The ZXR10 8512
1. There were always some users failing to get
switch was used for Layer 2 convergence.
online after dial-up and authentication. But they
PPPoE users were terminated on
could get online if they dialed up again or waited
UAS10600, and special line users were
for two minutes.
terminated on NE80E. Static back routes
2. When users fed back the problem, the
were configured on S8016 for the address
operation and maintenance personnel made some
pool configured on UAS 10600.
mock tests at the proximal end. There was no

problem.
3. The failure did not happen in any regular
pattern about time and geopolitical location.
Malfunction Analysis
1. Engineers checked the system configuration
and running state of UAS 10600. They found
no exceptions except that there were a lot of
broadcast packets received on the Layer 2 user
port connecting to 8512 per second.
2. To make sure that the large amount of
broadcast packets were not caused by network
factors such as virus, and to improve network
security, engineers configured an ACL on the 8512
Figure 1. Network Topology
switch to prevent common viruses. After that, the
www.zte.com.cn
amount of broadcast packets received on UAS
was not UAS 10600. According to the
10600 did not decrease.
longest mask matching rule, the packets
3. To know the contents of the broadcast
to 192.168.211.0/24 were forwarded to
packets, engineers connected a PC to the 8512
another device instead of UAS 10600.
switch and transmitted all VLANs to this port
Therefore, the user who obtained the IP
transparently. So engineers could get the broadcast
address 192.168.211.1/24 failed to get
packet contents through the PC. According to the
online.
information in the packets, besides the proper
8. If the user disconnected the
broadcast packets, there was a user scanning (the
connection and dialed up again, according
traffic was very little). Therefore, the failure was not
to the principle of poll-and-allocate address
caused by broadcast packets.
in the address pools on UAS 10600, it
4. The next day, engineers found that there
was possible for the user to obtain an IP
was a user sending more than 900 ARP broadcast
address in another segment. So the user
packets per second. Engineers checked the
could get online.
running of UAS 10600, and they found that the
The user could get online after waiting
device was running properly. Therefore, this was
for two minutes, because the user dialed
not the cause of the failure.
up again to obtain an IP address in
5. To reproduce the failure, engineers dialed up
another segment during this period.
and got offline repeatedly to conduct tests. At last,
The operation and maintenance
they found that the PC failed to get online when the
personnel made some mock tests at
PC passed the dial-up authentication and obtained
the proximal end but they did not find
the IP address 192.168.211.185. The PC could
any problem. This was because the IP
ping through the interface address on UAS 10600,
address obtained by the PC was not in the
but it could not ping through the interface address
segment 192.168.211.1/24.
on the peer device 8512. Therefore, engineers

considered that there was a fault about the route in
this segment.
Solution
Engineers informed the operation
6. There were 10 VBUI interfaces (there
and maintenance personnel to check the
were 10 address pools in total) on UAS 10600.
routing tables. It was found that the route
There were two Class-C addresses on each
to the segment 192.168.211.1/24 was
VBUI. The IP address of the VBUI to which the
advertised by the S8016. When the route
IP address obtained by the PC belonged was
was deleted, the fault did not occur any
192.168.210.1/23.
more.
Engineers checked the routes on the 8512

switch, as shown below.
According to the analysis, users

obtained the IP address with the incorrect
7. On the 8512 switch, the next hop address

of the route to the address 192.168.211.0/24
route, which caused the Internet access

failure.
Detination/Mask
Protocol
Pre
Cost
Nexthop
Interface
192.168.210.0/23
OSPF
10
11
10.10.239.146
Vlan-interface 4071
192.168.211.0/24
O_ASE
150
1001
10.10.239.137
Vlan-interface4096
Data Products
June 2010
Issue 219
Experience About POS Interface

Interconnection
Liu Peng / ZTE Corporation
Key words: POS, GER, CISCO
On a network, a ZTE GER router
command was used to check the port state, the

following result was displayed.
interconnected with a CISCO 6509 through
GER04#show interface pos3_2/1
POS interfaces. The network topology is
pos3_2/1 is up,
shown in Figure 1.
line protocol is down
The result shows that the link layer protocol is

down, and the connection cannot be established.
On the POS interfaces of GER04,

only IP addresses were configured. Other
parameters used the default values. The
configuration is shown below.
interface pos3_2/1
ip address
192.168.10.30
255.255.255.252
When the show interface pos3_2/1
When POS interfaces are used for

interconnection, there are some parameters
that must be considered. The following contents
describe these parameters in details according to
the configuration on the GER router.
clock source {internal | external | line}

This command is used to configure the line
clock. The keyword internal means to extract the

clock of the device its own. The keyword external
means to extract the clock from SMP. The keyword
line means to extract the clock from the line.
www.zte.com.cn
If two routers interconnect with each other
identify the type of load encapsulated in
back-to-back through POS interfaces, the clock of
SONET FOH. The range of the value is
one router should be set to internal, and the clock
0 ~ 255. Different values have different
of the other router should be set to line. By default,
meanings, as listed in Table 1(decimal is
the clock on POS interface of ZTE GER is internal.
used during configuration, and the value
crc {16 | 32}
listed below is in hexadecimal).
This command is used to configure the CRC
According to the list, if the scrambling
mode on a POS interface. The CRC mode can
function is enabled, the C2 value on the
be set to 16 bits or 32 bits. When two routers
POS interface should be set to 0X16. If
interconnect with each other through POS
the scrambling function is disabled, the C2
interfaces, the CRC modes of the interfaces should
value on the POS interface should be set
be consistent. By default, the CRC mode on ZTE
to 0XCF. By default, the C2 value on the
GER is 32.
POS interface of ZTE GER is 0X16, which
scramble { payload-disable | payload-enable}
corresponds to the scrambling function
This command is used to enable or disable
enabled on the POS interface.

Note: As the system of ZTE GER does
the scrambling function. By default, this function is

enabled on ZTE GER.
not support non-scrambling function in an
flag C2 <number>
SDH header, the C2 value 0XCF does not
C2 is the path signaling label. It is used to
take effect.
Table 1. SONET Payload Contents
Hex Value
SONET Payload Contents
flag J0 <number>
J0 belongs to the SOH byte. It is used
to detect the continuity of the connection
00
Unequipped.
01
Equipped-non-specific payload.
02
Vitual Tributaries (VTs) inside (default).
of different vendors. For example, devices
VTs in locked mode (no longer
of CISCO use 1-byte integer mode,
supported).
devices of HW use 16-byte character
04
Asynchronous DS3 mapping.
string mode, and devices of ZTE also use
12
Asynchronous DS-4NA mapping.
1-byte integer mode.
03
13
14
15
16
in section between two interfaces. The

configurations may be different on devices
Generally, the value of this field should
Asynchronous Transfer Mode (ATM)

cell mapping.
be consistent on both ends, especially
Distributed Queue Dual Bus (DQDB)
when this field is matched strictly on
cell mapping.
CISCO devices. Usually, this parameter is
Asynchronous Fiber Distributed Data
set to 0X01 on ZTE devices, which means
Interface (FDDI) mapping.
compatible. If there is any problem about
IP inside Point-to-Point Protocol (PPP)

with scrambling.
interconnection, it is also possible to set

the value to 0X01 on the peer. By default,
CF
IP inside PPP without scrambing.
the value of this field is 0xCC on the POS
E1-FC
Payload Defect Indicator (PDI).
interface of ZTE GER.
Test signal mapping (see ITU Rec.
FE
FF
G.707).
Alarm Indication Signal (AIS).
flag S1S0 <number>

S1S0 is the line synchronization state
label to set the synchronization state on
Data Products
June 2010
Issue 219
the line terminals. The range is 0 ~ 3. This
of the POS interfaces on the two devices. They
value is not defined in SONET standard
found that there was a parameter that must be
and it is not checked at the receiving side.
paid attention to, that is, the encapsulation type on
However, this value is defined in SDH
the POS interface. By default, the encapsulation
standard and it is checked at the receiving
mode on the POS interface of ZTE GER is PPP,
side. If the value is not equal to 2 at the
which cannot be modified. However, the default
receiving side, the interconnection will
encapsulation mode on the POS interface of
fail. By default, the value is 2 on the POS
CISCO device is HDLC.
interface of ZTE GER, which means SDH

frame format.
Engineers modified the encapsulation mode

on the POS interface of the CISCO device to PPP.
framing {sonet | sdh}
The link layer protocol was up, and the two devices
This command is used to configure
could ping through each other successfully.
the frame format on POS interfaces. The

frame format should be consistent on both
Summary
ends. If routers are connected through a

transport device, the frame format should
The default parameter values on the devices of

ZTE, HW and CISCO are compared in Table 2.
be consistent with that on the transport
During the configuration of POS interfaces,
device at the same time. By default,
do pay attention to the related parameters at both
the frame format is sonnet on the POS
sides, especially pay attention to the encapsulation.
interface of ZTE GER.
The configuration of encapsulation should be

consistent at both ends.
Solution
As the default encapsulation mode on the POS
In this malfunction case, even when all
interface of ZTE GER is PPP and it cannot be
parameters were set to keep consistent
configured, make sure that the encapsulation mode
with those of the peer CISCO router,
is set to PPP on the POS interface of the peer
the link layer protocol state on the POS
device when the two devices are interconnected
interface was still not up.
through POS interfaces. Otherwise, the link layer
Engineers checked the configuration
protocol cannot be up.
Table 2. The Devices of ZTE, HW and CISCO
ZTE
Huawei
CISCO
mtu
1500
1500
4096
CRC
32
32
16
Scrambling
scrambling
scrambling
No scrambling
C2
0x16
0x16
0xCF
S1S0
J0
0xCC
Clock source
Internal
Framing
Sonet
Encapsulation
PPP, cannot be configured HDLC
Adjusted automatically, cannot

be configured
NetEngine
Master (corresponding to
internal)
SDH
2
0xCC
Line
SDH
HDLC
www.zte.com.cn
VRRP Changeover Failure

Wu Lifeng / ZTE Corporation
Key words: T64E, VRRP, Track, firewall
Malfunction Description
VRRP ran between the routers and between
the firewalls. The devices interacted with VRRP
protocol packets through the specific heart
beaten line interfaces and were not affected by
the different segments on the heart beaten line
interfaces. When the optical fibers between the
Juniper firewalls and the T64E routers were
single-pass, as shown in Figure 1, the service
communication between the client connecting to
the firewalls and the server was interrupted.
Interface
Own Pre State

Group-addr
gei_1/4.12
N
Grp Pri Time

Master-addr
12
10.134.64.155
gei_1/3.3
N
gei_1/4.13
Y
13
gei_1/4.11
Y
gei_1/3.2
Y
gei_1/3.1
Y
130 14.492
130 14.492
130 14.492
Master 172.16.1.161
172.16.1.163
N
11
Master 10.7.29.153
10.7.29.155
N
130 8.492
Master 192.168.1.153
192.168.1.155
N
130 14.492
Master 192.168.1.161
192.168.1.163
N
130 14.492
Master 10.134.64.153
Master 10.7.29.161
10.7.29.163
2. The result showed that the VRRP

state was normal. Engineers pinged
the interface addresses on the Juniper
firewalls, but the addresses could not be
1. Engineers logged into R1 to check the VRRP
state, as shown below:
R1#show vrrp brief
Interface total: 12, Group total: 12,
Master total: 9
pinged through, as shown below:

R1# ping vrf juniper-mss
10.7.29.164
sending 5, 100-byte ICMP echoes

to 10.7.29.164, timeout is 2
seconds.
.....
Success rate is 0 percent(0/5).
Data Products
June 2010
Issue 219
3. Engineers checked FW-1. They
are interconnected with devices of other vendors,
found that the port on FW-1 was down.
usually the working mode of the ports is set to
At present the VRRP state was Backup.
mandatory mode. Otherwise, the interconnections
Engineers checked the problem and found
will fail. However, in this way, single pass through
that FW-1 did not receive optical signal
optical fiber is unavoidable. It is possible to solve
from R1. The reason was that, as the
the problem in the following methods:
working mode of the interconnected ports
1. One method is to configure a VRRP group to
on R1 and FW-1 was mandatory 1000 M,
trace the link state of a track. If the interface state
as long as R1 received optical signal, the
becomes down from up, the priority of the interface
port would be up and VRRP changeover
decrements. If the interface state becomes up from
would not be implemented.
down, the priority of the interface increments to
R1#show interface gei_1/3

gei_1/3 is up,
up
line protocol is
Description is TO_XHP-JUNIPER1_gei_1/1
Solution
speed up the election of VRRP Master router.

In fact, the working principle of a track is also
based on the up/down working mechanism of a
port. Therefore, this method is not feasible.
2. The second method is the IP address
based detection mechanism. At present, Juniper
firewall supports this protocol. Even when a fault
Engineers disconnected the other
occurs on the port, the state displayed is still UP.
optical fibers on the Juniper firewalls. The
As long as the address of this port cannot be
services were recovered.
pinged successfully, VRRP changeover will not be
Summary
For VRRP routers, only the Master
router is responsible for forwarding the
implemented.
3. Another method is to add a switch. Figure
2 shows a typical network architecture. It is
recommended to use this method.
packets with address that is associated

to the virtual router and responding to the
ARP requests for this IP address. In the
situations such as priority is not configured
manually, VRRP is implemented according
to the state of ports.
In this malfunction case, the VRRP
state on the routers was not changed over.
However, FW-1 found that the uplink was
interrupted, so FW-1 changed over all
services to FW-2 to send the services to
R2. As R2 was the Backup VRRP router,
it would not handle with the ARP requests.
Therefore, the services were interrupted.
In existing network, when ZTE devices
10
Figure 2. Typical Network Architecture
In brief, when there was the switch (shown in

Figure ) on the network, conduct tests about VRRP
hardware handover and VRRP logical changeover.
www.zte.com.cn
Attentions for Configuring Out-of-Band

and In-Band NM on UAS
Liu Peng / ZTE Corporation
Key words: UAS, device management, in-band management, out-of-band management,
Netnumen
Network Topology
The broadband access network of a service
provider used ZTE GER/UAS10600/T40G/
FASP9800 network structure. The network topology
is shown in Figure 1. It was required

to manage the devices through private
network addresses.
After communicating with the office
Data Products
11
June 2010
Issue 219
personnel, engineers combined in-band

network management and out-of-band
network management to build the network
for network management.
For UAS devices and GER routers,

engineers configured private network
addresses through out-of-band
management interface to connect the
devices to VPN and then interconnect
them to the Netnumen Server.
For T40G switches and the downlink

devices, as there were quire many
devices, it was impossible to provide
an individual out-of-band management
link for each device. Therefore,
engineers used in-band network
management:
interface vbui11
ip address 192.168.10.1 255.255.255.0

ip host 192.168.10.2 slot 1 port 3
vlan 199
/*Add the network addresses of T40G
and downlink devices in IP host mode*/

ip host 192.168.10.3 slot 1 port 3
vlan 199
Configuration related to out-of-band network

management:
nvram mng-ip-address 192.168.10.4
255.255.255.0
There was no information indicating
port on each T40G switch, thus
alarms or errors during the configuration. If the
connecting the devices to VPN after
configurations were feasible, it was only necessary
aggregation and then interconnecting
to configure network management addresses in
them to the Netnumen Server.
192.168.10.0/24 segment for T40G switches and
H o w e v e r, i t w a s o n l y p o s s i b l e
downlink devices in the network.
to manage the devices through the
After the configuration, engineers checked
Netnumen Server or the VPN network in
whether the devices were reachable on UAS, as
out-of-band network management mode.
shown below:
Server, or when the VPN was unavailable,

engineers could not manage T40G
switches and the downlink devices.
For security, engineers configured
Layer 3 interfaces on T40G switches
and UAS devices. Therefore, once the
out-of-band network management was
unavailable, engineers could telnet to
T40G switches and the downlink devices
through UAS devices. In this way, it is
possible to manage all devices through the
private network, which was convenient for
routine maintenance and remote diagnosis
when faults occurred on the devices.
To make the configuration as simple
as possible, engineers configured the
Configuration related to in-band network
management mode through a service
Once a fault occurred on the Netnumen
12
following commands on UAS.
ZXUAS#Ping mng 192.168.10.2
/*ping
the management address of T40G on the

out-of-band management interface*/
sending 5,100-byte ICMP echos to
192.168.10.2,timeout is 2 seconds.
!!!!!
Success rate is 100 percent(5/5),roundtrip min/avg/max= 0/0/0 ms.

ZXUAS#ping 192.168.10.2
/*
ping the management address of T40G on

the in-band management interface*/
!!!!!
Success rate is 100 percent(5/5),roundtrip min/avg/max= 0/4/20 ms.
www.zte.com.cn
The information showed that T40G could be
segment as the address segment of T40G
pinged successfully through in-band and out-of-
and the downlink devices for in-band
band management interfaces. As the out-of-band
management through UAS. The address
management interface of UAS and the specific
segment was 192.168.11.0/24. That is,
management interface of T40G were connected
T40G and the downlink devices used
to the same HUB and they were in the same
segment 192.168.10.0/24 as the out-of-
segment, T40G could be pinged successfully
band network management addresses,
through the out-of-band management interface.
and used segment 192.168.11.0/24 as the
Meanwhile, engineers added the addresses of
in-band network management addresses.
T40G and the downlink devices by setting IP
After the modification, engineers
host through VBUI11 interface on UAS, so T40G
checked the states on the devices. There
could be pinged successfully through the in-band
was no alarm.
management interface.
Summary
On UAS 10600 or UAS 10800E,
If users used the in-band address 192.168.10.1
no stipulate defines that the in-band
as the network management address of UAS
management address and the out-of-band
and then added an NE through Netnumen,
management address cannot be in the
alarms indicating that the NE was disconnected
same segment. In practical configurations,
periodically occurred on the NE.
the two addresses can even be the same
Meanwhile, if users used the in-band address
IP address.
192.168.10.4 as the network management address
To use in-band management and out-
of UAS and then added an NE through Netnumen,
of-band management at the same time,
the NE state was steady and the connection was
it is necessary to avoid using the in-band
normal.
management address and the out-of-band
Solution
management address that are in the same

segment and to ping through each other
In this special network management structure,
successfully. Users can solve such problems
engineers used the following method to solve the fault.
through physical isolation or by dividing the
Engineers used another private network
two addresses in different segments.
Data Products
13
June 2010
Issue 219
High CUP Usage Caused by Route Loop

Fu Tao / ZTE Corporation
Key words: ICMP, route loop, CPU usage
there were packets lost. When they pinged remote
Internet bar users said that when they

pinged the gateway switch ZXR10 3952,
websites, the delay was normal and download was

normal.
the delay was long, with the average delay
The network topology is shown in Figure 1.
about more than 200 ms, and sometimes
address of the Alcatel router. The delay was about
1. Engineers logged in to ZXR10 3952
200 ms.
and pinged the user address to conduct
Engineers connected a PC to the switch and
tests. They found that the delay was long,
pinged the Alcatel router, the delay was also about
with the average delay about 202 ms. The
200 ms.
Engineers executed show process command to
maximum delay was 300 ms.

Engineers pinged the interconnection
check the CPU usage. It was 22%, as shown below:
ZXR103952#show process
M: Master processor
S: Slave processor
Peak CPU: CPU peak utility measured in 2 minutes

PhyMem: Physical memory (megabyte)
Memory
MP(M)
34.662%
Panel
1
CPU(5s) CPU(30s) CPU(2m)

22%
22%
2. Engineers enquired about the CPU

usages on other ZXR10 3952 switches.
14
22%
Peak CPU
33%
PhyMem
256
Buffer
0%
the same traffic. Obviously, the CPU usage of this

XR10 3952 switch was much higher.
They were told that the CPU usages were
Engineers executed the show logging alarm
about 10% on other switches with about
command but they did not find any alarms for
www.zte.com.cn
exceptions such as ARP attack and so on. They
that the count of badhop increased quickly
executed the show ip traffic command and they found
during a short period, as shown below:
ZXR103952#show ip traffic
IP statistics:
Rcvd: 1376900 total, 200638 local destination

format errors
checksum errors
unknown protocol
0
Frags:reassembled
0
timeouts
bad hop count

29614
couldn't reassemble
3. Engineers checked the switch and they found
delay, and even some packets were lost.
that there was only one default route directing to
User could download and ping websites
the Alcatel router. Therefore, engineers doubted
properly, because those packets might be
that the high CPU usage was caused by too many
only forwarded instead of being handled
packets with TTL=1 sent to CPU due to a route
with by the CPU on the ZXR10 3952
loop. As a result, the CPU was busy handling with
switch.
these packets with TTL=1.
To validate the surmise, engineers
As the CPU usage was high, the ping packets

of the Internet bar users were handled with after a
executed the debug ip icmp command on

the switch. The result is shown below:
05:17:27
IP
ICMP:sent
type
time
exceeded,
code
0,
src
05:17:28
IP
ICMP:sent
type
time
exceeded,
code
0,
src
05:17:29
IP
ICMP:sent
type
time
exceeded,
code
0,
src
05:17:30
IP
ICMP:sent
type
time
exceeded,
code
0,
src
05:17:40
IP
ICMP:sent
type
time
exceeded,
code
0,
src
172.16.237.118,dst 123.55.214.19
172.16.237.118,dst 192.168.33.54
172.16.237.118,dst 192.168.33.54
172.16.237.118,dst 123.55.214.19
172.16.237.118,dst 58.215.81.76
4. The result showed that the ZXR10 3952
debug ip source 192.168.33.54 command
switch received ICMP packets with TTL=1 from
(take the IP address 192.168.33.54 as an
123.55.214.19 and 192.168.33.54. As the TTL
example) to view the detailed information,
values of these packets were 1, these packets were
as shown below:
sent to the CPU for handling. Engineers executed

ZXR103952# debug ip source 192.168.33.54
IP source debugging is on
WeiXiaoXiJie3952#
05:40:14 IP source:192.168.33.54 forward src 192.168.33.54(vlan2),dst
Data Products
15
June 2010
Issue 219
10.10.74.9(vlan2)

10.10.74.9(vlan2)

10.10.74.9(vlan2)

10.10.74.9(vlan2)
5. The information showed that the
10.10.74.9 belonged to by executing show ip
destination of the packet with the source
route connected command on the ZXR10 3952
address 192.168.33.54 was 10.10.74.9.
switch. Therefore, the packet was sent back to the
This packet could reach the ZXR10
router according to the default route.
3952 switch, so there must be a route
In this way, a loop was formed between the
heading for the segment which 10.10.74.9
ZXR10 3952 switch and the router. To validate the
belonged to directed to the ZXR10 3952
surmise, engineers traced the destination address
switch. However, engineers did not find
10.10.74.9 on the ZXR10 3952 switch, as shown
any direct-connected segment which
below:
ZXR103952# trace 10.10.74.9
tracing the route to 10.10.74.9
1 172.16.237.117
260 ms
220 ms
2 172.16.237.118
240 ms
240 ms
on the router*/
interconnecting to the router*/

3
According to the analysis, engineers

found that there was a route loop. There
were three methods to solve the problem.
1. Configure an extended ACL to filter
/*address of the interface
on the router, engineers checked the CPU usage

again. The CPU usage and the delay of ping
packets were normal.
Summary
the addresses that were unreachable on
When the device receives a packet with
the uplink interface of the ZXR10 3952
TTL=1, it will send an ICMP time-out packet to the
switch
remote source address. The source address of this
2. Configure black hole routes directing
time-out packet is an address on this device, and
to the unreachable segments on the
the destination address of this packet is the remote
ZXR10 3952 switch
source address.
3. Delete the useless static route

configuration on the router
The third method met the requirements
of network configuration specifications.
After deleting the useless static routes
240 ms
/*address of the interface
Solutions
16
220 ms
The debug ip source <ip-address> command can

be used to view the related information in detail of
the packet with this IP as its source address, such
as the destination address, and so on.
www.zte.com.cn
Service Interruption after Capability

Extension
Liu Jiangdong / ZTE Corporation
Key words: HSRP, MAC drafting, group number
The network topology is shown in Figure 1. As
were assigned to the RNSc and BSCs in

machine room 2. After the changeover,
some new 2G sites and 3G sites of an office were

added, the loads of RNCs and BSCs in the original
machine room were not enough. It was necessary
to extend the capabilities of a device group in
machine room 2. After the capability extension, the
coupling from some 2G and 3G base stations to
the RNCs and BSCs was intermittent.
The two CISCO 6513 in machine room 1
enabled HSRP protocol to work as the gateway
of the base stations. T64G only executed Layer 2
transparent transmission. Services run properly
before the capability extension.
After the capability extension, the group of
the devices in machine room 2 also used HSRP
protocol to work as the gateway. Some sites
Data Products
17
June 2010
Issue 219
however, the communications of the sites

assigned to the two machine rooms were
After the malfunction occurred,
engineers took the following steps:
1. Engineers checked whether there
was any alarm information on CISCO6513.
But they did not find any exception.
2. Engineers checked the routes to
RNCs and BSCs on CISCO6513. They
found that static route load sharing
was configured from RNCs and BSCs
to CISCO6513. The static route load
sharing entry was proper. Engineers could
ping RNCs and BSCs successfully on
standby 1025 preempt delay minimum
10
standby 1025 authentication md5
key-string HSRP
The related configuration on CISCO6513 in

machine room 2 is shown below:
interface Vlan25
description
###connected
T64G_2_GEI_1/18###
ip
address
255.255.255.0
to
10.10.25.252
standby version 2
standby 1025 ip 10.10.25.254
CISCO6513.
At the base station side, CISCO6513
connected to the base stations through
direct-connected segments. They could
ping each other successfully. Engineers
checked the ARP entries. There were ARP
entries to the base stations, but they were
not steady and were learnt repeatedly and
discontinuously. Therefore, there were
some problems.
3. Engineers checked ZXR10 T64G
switches. They found that there were a lot
of alarms indicating MAC address drifting.
The MAC address was the virtual MAC of
the HSRP gateway on the base stations.
4. Engineers checked the HSRP
configuration of Layer 3 VLAN on
CISCO6513.
The related configuration on
CISCO6513 in machine room 1 is shown
below:
standby 1025 timers 2 5
standby 1025 priority 110
standby 1025 preempt delay minimum
10
standby 1025 authentication md5
key-string HSRP
According to the configuration, the standby
group numbers were the same. According to

the information provided by CISCO, the last
several bits of the virtual MAC address in HSRP
are calculated according to the group number.
Therefore, the same HSRP group resulted in the
same MAC address. As a result, MAC drafting
occurred on ZXR10 T64G switches in this network
environment, and the fault occurred.
Solution
Engineers modified the related configuration
of the HSRP group number on the same Layer
3 interfaces. The services were recovered. The
coupling from some 2G and 3G base stations to
interface Vlan25
the RNCs and BSCs was proper. The ARP entries
description ###connected to
on CISCO6513 were steady.
ip
VRRP, it is also necessary to avoid using the same
T64G_1_GEI_1/18 ###
address
255.255.255.0
10.9.25.252
standby version 2
standby 1025 timers 2 5
standby 1025 priority 110
intermittent.
18
standby 1025 ip 10.9.25.254
We can associate VRRP from CISCO HSRP. In

VRRP group numbers in such network structures.
www.zte.com.cn
Attention for MPLS Label Configuration

Wang Feng / ZTE Corporation
Key words: ACL, MPLS, label, loopback address, FEC
At present, for the VPN configuration on ZXR10
T128/T64E of Version 2.6.02 or previous versions,
usually ACL is configured to control the generation
of labels, as shown below:
mpls ip
mpls ldp router-id loopback1

mpls ldp access-fec for 1
distribute labels.
The new label is ready, but restarting
the MPLS process will interrupt the
services.
Therefore, it is necessary to configure
mpls ldp access-fec host-routeonly command during the MPLS VPN
configuration.
This command is to generate labels
acl standard number 1
for host-routes only, and not to generate
0.0.0.0
or interconnected segments between
0.0.0.0
the labels distributed for the loopback
rule 1 permit 192.168.66.30
labels for routes of service segments
rule 2 permit 192.168.98.27
devices. In this way, for VPN services,
rule 3 permit 192.168.128.119
addresses of the PE devices are enough.
rule 4 permit 192.168.128.118
distributed for the loopback addresses
0.0.0.0
0.0.0.0
rule 5 permit 192.168.128.117
0.0.0.0
The advantage is that the number of the labels

generated by the device can be controlled. This
However, unnecessary labels may be

of the devices that do not work as PEs.
When there are a lot of devices on the
entire network, many labels will be wasted.
Solution
saves the valuable memory resources of the device
During the MPLS configuration on
effectively. However, there is a trouble under the
ZXR10 T128/T64E of Version 2.6.02 or
situation when it is necessary to distribute a label
previous versions,
for the loopback address of a new added PE
on the network, it is recommended
device.
to use the configuration that only
In such a situation, is it only necessary to re-
distributes labels for host-routes.
compile the ACL? If so, ACL is changed, but the

number of labels does not increase, and the label
When there are not too many devices
When there are many devices on the
of the new added PE cannot be viewed. Therefore,
network, but the number of PE devices
it is also necessary to restart the MPLS process
is steady (that is, PE devices will not be
to make it use the ACL that has been modified to
added randomly), it is recommended
Data Products
19
June 2010
Issue 219
to use ACL to control the generation of
any more. It is only necessary to execute the
labels.
mpls ldp access-fec force command after ACL
It is recommended to use one of the
modification. The new ACL will take effect at once.
methods when MPLS is configured.
This procedure will not affect the running services.
A new function is added on ZXR10
At present, this function has been applied on
T128/T64E of Version 2.6.03B, that is,

FEC takes effect immediately.
current networks. It has good effect.

Therefore, it is recommended to use the ACL-
When the ACL-based policy is
based policy to control the number of labels
configured to restrict the number of labels,
distributed to devices when MPLS is configured
if the ACL needs modification, it is not
on ZXR10 T128/T64E of Version 2.6.03B or later
necessary to restart the MPLS process
versions.
Website Access Failure in MPLS VPN

Qu Zhihui / ZTE Corporation
Key words: MPLS, VPN, MTU, fragment, WWW, label
departments. The VPNs communicated with the
On the government network of a
VPN of province level. On the previous network,
city, MPLS/VPN technology was used to
CISCO7206 worked as the PE device and
construct VPNs for different administration
established MP-BGP neighbor relationship with

the PE device (CISCO GSR12000) in the VPN of
province level.
To improve the network performance and
construct the MPLS VPN network covering levels
of province, city and county, ZXR10 T64G was
used as the PE device of city level. It established
MP-BGP neighbor relationship with the PE device
of province level. Meanwhile, ZXR10 T64G worked
as the route reflector and established MP-BGP
neighbor relationship with the PE devices of county
level.
The government network topology before
Figure 1. Government Network Topology Before Update
20
update is shown in Figure 1.
www.zte.com.cn
The government network topology after the

update is shown in Figure 2.
5. According to the information,

the WWW server in Site A replied with
After the government MPLS/VPN network
some packets. So there was no problem
was rebuilt, users in Site B failed to access the
about the routes in the VPN. Engineers
homepage of the WWW server in Site A.
found that the fragment field in the IP
1. Engineers checked the devices. The fault did
exist.
packets were set to fragment not allowed.

Engineers inferred that the network card of
the WWW server was set not to fragment
the packets.
2. Engineers could not ping the WWW server in

Site A successfully from the PC in Site B. But they
could ping the VRF interface address of VPN1 in
Site A successfully.
3. Engineers connected the CE device in Site
B to CISCO7206 again. Then engineers could
not ping the WWW server in Site A successfully
from the PC in Site B. But they could access the
homepage of the WWW server. Therefore, ICMP
filter function was enabled on the network in Site A.
There might be no problem about the routes in the
VPN.
4. As it is impossible to find out the problem
with the ping tool, engineers captured packets to
obtain more information. They connected the CE
device in Site B to ZXR10 T64G again. Engineers
captured packets with SNIFFER software when the
PC in Site B accessed to the WWW server in Site A.
The packet information is shown in Figure 3.
Figure 2. Government Network Topology After Update
Figure 3. The Packet Information
Data Products
21
June 2010
Issue 219
The maximum length of a proper HTTP

packet is 1500 bytes. As the packet was
as described below:
transmitted in MPLS VPN, after it was
1. Before the network update, in normal
encapsulated with two layers of MPLS
situations, the HTTP request packets or the TCP
labels (in the situation of penultimate hop
acknowledge packets sent to the WEB server in
popping, the external label was popped up,
Site A by the PC in Site B were small packets.
and only one VPN label left), the length of
Even if the packets were encapsulated with two
the packet was more than the default MTU
layers of MPLS labels, the length was still less than
(1500 bytes). If the devices on the MPLS
1500 bytes. Therefore, there was no problem if
network did not support to transmit jumbo
the interconnected interfaces on CISCO7206 and
frames and the packet was not allowed
CISCO GSR used the default MTU.
to be fragmented, the packet would be
2. Generally, the length of the HTTP packets
dropped. An ICMP packet would be sent
sent to the PC in Site B by the WEB sever in
to the source of this packet, indicating that
Site A was 1500 bytes. After the packets were
the device received a packet of which the
encapsulated with two layers of MPLS labels, the
length was more than the MTU but the
total length was more than the default MTU (1500
packet was not allowed to be fragmented.
bytes) consequentially. The CISCO GSR device
Solution
22
according to the traffic model of the HTTP access,
supported to forward jumbo MPLS frames. When

CISCO7206 received the jumbo MPLS frames, as
Preliminarily, it was considered that the
it worked as the PE device, the packets forwarded
fault was caused as the MTU of the path in
on the VRF interface were common IP packets
the MPLS VPN was smaller than the size
and the MPLS header information was removed.
of the MPLS frame. Which was the device
Therefore, the length was not more than 1500
with the MTU bottleneck in the MPLS
bytes. As a result, the PC in Site B could access
domain?
the WEB server in Site A.
The NP chip of ZXR10 T64G supported
3. After the network update, ZXR10 T64G
to forward jumbo MPLS frames, therefore,
worked as the PE device, and CISCO7206 worked
the fault was not caused by ZXR10 T64G.
as the P device. If the length of an HTTP packet
As the CISCO GSR device also supported
sent to Site B from Site A was 1500 bytes, when
to forward jumbo MPLS frames, the
this packet was forwarded to CISCO7206, as
fault might be caused by CISCO7206.
ZXR10 T64G enabled penultimate hop popping, the
Engineers informed the agent to modify
packet forwarded to ZXR10 T64G by CISCO7206
the MTU on the interface of CISCO7206 to
contained an MPLS label. That is, the VPN label.
1544. The fault was solved.
As a result, the length of this packet was more than
Why could Site B access the WEB
the default MTU (1500 bytes), and so the packet
server in Site A before the network
was dropped. This was why the PC in Site B could
update? Engineers analyzed the reason
not access to the WEB server in Site A.
www.zte.com.cn
Access Failure Caused by MRU

Wu Lifeng / ZTE Corporation
Key words: MPLS, VPN, MRU, MTU, GER
Network Topology
As shown in Figure 2, ZXR10 T1200 worked as
a P device. ZXR10 T64E worked as a PE device,
and users connecting to ZXR10 T64E could access
Internet properly. GER worked as a PE device, and
users connecting to GER could only open baidu. They
could not open other portals, such as sina, sohu, and
so on.
Engineers could ping baidu successfully
on PC2, but they could not ping sina and sohu

successfully.
2.
echos to 10.6.0.13,timeout is
1 seconds.
...........
Success
percent(0/11).
rate
is
3. According to the above steps,

engineers affirmed that there was no
1.
sending 20,1493-byte ICMP
Engineers pinged the interface address of
PING NE40 on GER, as shown below:
problem about the VPN routes. The problem

may be the MTU parameter configuration
on the downlink interface of ZXR10 T1200
connecting to GER.
Engineers checked the configuration on
the interfaces of ZXR10 T1200 connecting
to T64E and GER. They found that the MTU
GER-1#ping vrf vpn-mss 10.6.0.13
was 1600 and the MRU was 7600 on ZXR10
NE40*/
was 1700 on T64E. The MTU was 1500 and
/*the address of the PE device

!!!!!
T1200. The MTU was 1600 and the MRU

the MRU was 1500 on GER.
MRU indicates Maximum Receive Unit.
Success rate is 100 percent(5/

5),round-trip min/avg/max= 0/8/20
ms.

option 20 1492 1

!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent(20/
20),round-trip min/avg/max= 0/5/20

ms.

option 20 1493 1
Data Products
23
June 2010
Issue 219
It is the maximum length of a packet that can
The forwarding intermediate nodes did not support
be received. If the length of a packet is more
fragment, so the jumbo packets were dropped directly.
than the MRU, this packet will be dropped.
3. At the GER side: On the incoming direction, it
MRU effects on the ingress interface when
was only necessary to check the MRU. Generally, the
the device receives traffic, that is, MRU is
length of an HTTP packet sent from the Internet to
uplink-valid.
PC2 was 1500 bytes or even larger. After the packet
MTU indicates Maximum Transit Unit.
was encapsulated with two layers of MPLS labels,
It is the maximum length of a packet that
the total length of the packet was consequentially
can be forwarded. If the length of a packet
more than the default MRU (1500 bytes). The MRU
is more than the MTU, the packet will be
on the interface of GER was 1500 bytes. Therefore,
dropped or fragmented. MTU effects on the
the packets with length more than 1500 bytes were
egress interface when the device forwarding
discarded.
traffic, that is, MTU is downlink-valid.

Engineers analyzed the data forwarding
flow, as described below:
total length of the packet was more than the default
as the reference points. On the outgoing
MRU, and so the packet was discarded. Therefore,
direction, it was only necessary to check the
engineers could not ping successfully with packet
MTU. The length of the HTTP request packet
length more than 1492 bytes from PC2.
Internet by PC2 was 1492 bytes (L2 packet
Solution
length = L3 packet length + 18). Even if the
Engineers modified the MTU on GER to 1500
packet was encapsulated with two layers of
bytes. The fault still persisted. As GER of the current
MPLS labels, the total length was still less
version did not support MRU modification, engineers
than 1500 bytes. Therefore, there was no
upgraded the device to V2.6.03.B.52.P10 and then
problem from PC to the Internet.
modified the MRU to 1608 bytes. The fault was solved.
2. At the T64E side: On the incoming

direction, it was only necessary to check
one MPLS label, that is, the VPN label. As a result, the
1. On the network, take PC1 and PC2
or TCP acknowledge packet sent to the
24
GER enabled penultimate hop popping by default,

so the packet forwarded to GER by T1200 contained
Summary
the MRU. Generally, the length of an HTTP
For cases that jumbo packets cannot be pinged
packet sent from the Internet to PC1 was
successfully, we usually take the MTU configuration
1500 bytes or even larger. After the packet
into account first. We usually ignore the MRU,
was encapsulated with two layers of MPLS
because the default MRUs on many devices are large
labels, the total length of the packet was
and these devices do not support MRU modification.
consequentially more than the default MRU
The default MRU values on devices of V2821 are
(1500 bytes). The MRU on the interface
listed below:
of T64E was 1700 bytes. Therefore, on
Ethernet interface (fei, gei and xgei): 7600 bytes
the incoming direction, the packets with
Oc interface (pos48 and pos12): 7600 bytes
the length less than 1700 bytes could be
Oc interface (pos3): 1700 bytes
forwarded.
Atm interface (atm622): 7600 bytes
If there were jumbo packets with
Atm interface (atm155): 1700 bytes
the length more than 1700 bytes, it was
Oc interface (cpos3): 1700 bytes
necessary to take fragment into account.
Ce1 interface: 7600 bytes
www.zte.com.cn
VPLS Service Failure on T160G

Yang Fei / ZTE Corporation
Key words: T160G, VPLS, NP pinch plate
Network Topology
The network topology is shown in Figure 1.
xconnect vfi test
interface fei_1/1
switchport access vlan 200
interface fei_1/2
mpls ip
mpls
ldp
61.139.36.33
target-session
ip route 0.0.0.0 0.0.0.0

59.43.1.2
The configuration related to VPLS on

T160G-2 is shown below:
Two T160G switches interconnected with each

other through VLAN 100 on interfaces fei_1/2.
PCs were connected to the switches through

VLAN 200 on interfaces fei_1/1.
It was required to make the PC ping each other

successfully through VPLS function on the
switches.
The configuration related to VPLS on T160G-1
is shown below:
pwtype ethernet-vlan
peer 61.139.36.33
interface loopback 1
255.255.255.255
interface vlan 100
61.139.36.34
ip address 59.43.1.1 255.255.255.252

mpls ip
interface vlan 200
pwtype ethernet-vlan
peer 61.139.36.34
interface loopback 1
ip address 61.139.36.33
255.255.255.255
interface vlan 100

ip
address
255.255.255.252
59.43.1.2
interface vlan 200
vcid 200
address
vcid 200
mpls ip
vfi test
ip
vfi test
xconnect vfi test
interface fei_1/1
interface fei_1/2
mpls ip
mpls
ldp
61.139.36.34
target-session
ip route 0.0.0.0 0.0.0.0

59.43.1.1
Data Products
25
June 2010
Issue 219
After the configuration, when engineers set the PCs to be in the same segment 1.1.1.0/24, the
PCs could not ping each other successfully.
1. Engineers checked the VC states on the two switches. The VC states were up, as shown
below:
T160G-1#show mpls l2transport vc vpls vfi test
VFIName
Test
LocalCircuit
VFI
DestAddress
61.139.36.33
Test
LocalCircuit
VFI
Status
VC ID
Status
200
T160G-2#show mpls l2transport vc vpls vfi test

VFIName
VC ID
DestAddress
61.139.36.34
200
up
up
2. Engineers checked the distribution of out-labels on the two switches. The labels were
proper, as shown below:
T160G-1#show mpls forwarding-table
Mpls Ldp Forwarding-table:
InLabel
53
OutLabel
Dest
101712
Pfxlen
61.139.36.33
32
Interface
NextHop
fei_1/2
59.43.1.2
T160G-2#show mpls forwarding-table

Mpls Ldp Forwarding-table:
InLabel
101711
OutLabel
54
Dest
61.139.36.34
Pfxlen
32
Interface
fei_1/2
NextHop
59.43.1.1
3. Engineers checked the distribution of in-labels on the two switches. The labels were proper.
4. Engineers checked the MAC learning on the two switches. They found that the switches
could not learn the MAC addresses of the PCs, as shown below:
T160G-1#show mac vfi test
MAC
peer-address
outIntLab
T160G-2#show mac vfi test

MAC
peer-address
outIntLab
outExtLab
outInterface
type
outExtLab
outInterface
type
5. Engineers thought that this fault was caused by the PCs, network cables or the ports on
the switches. They replaced the PCs, network cables and the ports on the switches. The fault
persisted.
6. Engineers entered diagnosis mode to check the micro code versions of the NP pinch plates
on the two switches. They found that the micro code versions of the NP pinch plates on T160G
switches were the default proper version, as shown below. However, to support VPLS function, G
series devices should use NP pinch plates with micro code of vpn version.
T160G-1 (diag)#npc 1 np chip-info microcode-version
26
www.zte.com.cn
Mcode normal version is running!

T160G-2(diag)#npc 1 np chip-info
microcode-version
Mcode normal version is running!
Solution
T160G-2(config)#net-card vpn
T160G-2#reload slot 1
Summary
To support VPLS service, G series
switches need NP pinch plates. There is
Engineers modified the version of NP pinch
one more condition, that is, the micro code
plates to vpn on the switches and then reset
version of the NP pinch plates must be
the two boards. MAC addresses could be
vpn. By default, the micro code version of
learnt properly, and the PCs could ping each
the NP pinch plates is proper. Therefore,
other successfully. The fault was solved. The
it is necessary to modify the micro code
configuration commands are shown below:
version and reset the boards plugged in
T160G-1(config)#net-card vpn
T160G-1#reload slot 1
the slots corresponding to the NP pinch

plates.
Experiences About Flow Mirroring

Configuration on ZXUAS 10800
Wang Huali / ZTE Corporation
Key words: ZXUAS 10800, mirroring, PPPoE, IPoE, subscriber
As shown in Figure 4, 9806E router connected
to the port Ethernet 1/2 of UAS 10800. A
modem connected to the 9806E router. Local
authentication was configured on UAS 10800. The
modem obtained IP address, DNS server address
successfully. However, the PC did not

capture any PPPoE dialing packets.
The configuration of traffic mirroring on
UAS 10800 is shown below.
and other information through PPPoE dialing to get

online.
It was required to mirror the traffic on port 1/2
to port 1/10 and use a PC to capture packets for
analysis. After traffic mirroring was configured,
the modem could dial up to obtain IP address
Data Products
27
June 2010
Issue 219
context pppoe9806e
domain 9806e.com
forward policy mirror2
/*create a forwarding policy
mirror2*/
mirror destination
mirror_dest2 all
/*mirror all traffic to the
logical target mirror_dest2*/
interface mirrorport
ip address 88.1.1.1/24
!
interface pppoe_9806e
multibind
ip address 10.12.102.1/24
ip pool 10.12.102.0/24
!
subscriber default
ip address pool
dns primary 172.24.242.242
!
subscriber name tw
password tw
port ethernet 1/2
description to_9806e
no shutdown
encapsulation pppoe
bind authentication chap pap
maximum 500
forward policy mirror2 in
/*incoming traffic mirroring*/
forward policy mirror2 out
/*outgoing traffic mirroring*/
port ethernet 1/10
medium speed 100 duplex half
no shutdown
bind interface mirrorport
pppoe9806e
/*bind to an interface*/
forward output mirror_dest2
/*the destination mirroring
port working as the egress of
mirror_dest2*/
[local]Redback(config)#show
detail
ethernet 1/10 state is Up
Description
Line state
Admin state
Link Dampening
disabled
Undampened line state
Dampening Count
Encapsulation
ethernet
MTU size
Bytes
NAS Port Type
Speed
Mbps
Duplex mode
MAC address
00:30:88:01:79:05
Media type
100Base-TX
Loopback
Active Alarms
port 1/10
:
: Up
: Up
: Up
: 0
: 1500
:
: 100
: half
:
:
: off
: NONE
Engineer executed show port counter 1/10

command. They found that there were several
thousand broadcast packets. This meant that the
traffic was not mirrored to port 1/10.
Solution
Engineers modified the configuration, as shown
below:
subscriber default
ip address pool
dns primary 172.24.242.242
forward policy mirror2 in
forward policy mirror2 out
Tr a f f i c m i r r o r i n g s u c c e e d e d a f t e r t h e
configuration was modified. The PC could capture
the PPPoE dialing packets.
The malfunction reason was that PPPoE
1. According to the situation, traffic

mirroring did not succeed. Engineers
PPoE, it was necessary to apply the forwarding
checked the configuration commands
policy to subscriber.
commands were correct.
There was no exception, as shown below.
encapsulation was enabled on port 1/2, and for
according to the configuration manual. The
28
2. Engineer checked the state of port 1/10.
Traffic mirroring function is only valid to IP

traffic.

Maintenance Experience Issue219 (Data Products) PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Maintenance Experience Issue219 (Data Products) PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Preface

In this issue of ZTE's Maintenance Experience, we continue

Maintenance Experience Editorial Committee

South, Shenzhen, P.R.China

LACP Configuration on ZXR10 8902 Switch.............................................................................................. 2

LACP Configuration on ZXR10 8902 Switch

Key words: ZXR10 8902, LACP, SmartGroup, active

interface in a dynamic aggregation group.

system MAC address, interface priority,

necessary to negotiate this parameter with the

port number and operation key. When

device compares the information with

make an agreement on the joining or leaving of an

LACPDUs to advertise its system priority,

r e c e i v i n g t h e i n f o r m a t ion, the peer

can be aggregated. In this way, both devices can

2. Set the SmartGroup working mode to 802.3ad (LACP).

3. Create the VLAN 200.

ZXR10-8902(config-gei_1/23)#switchport mode trunk

ZXR10-8902(config-gei_1/23)#switchport trunk vlan 200

The configuration information on gei_1/23 is shown below.

switchport mode trunk

switchport trunk vlan 200

smartgroup 1 mode active

The LACP state is shown below.

Flag *--LOOP is TRUE

Sporadic Internet Access Failure

Key words: UAS 10600, address pool, route, VBUI

The network phenomena are described as

is shown in Figure 1. The ZXR10 8512

1. There were always some users failing to get

switch was used for Layer 2 convergence.

online after dial-up and authentication. But they

PPPoE users were terminated on

could get online if they dialed up again or waited

UAS10600, and special line users were

for two minutes.

terminated on NE80E. Static back routes

2. When users fed back the problem, the

were configured on S8016 for the address

operation and maintenance personnel made some

pool configured on UAS 10600.

mock tests at the proximal end. There was no

switch to prevent common viruses. After that, the

amount of broadcast packets received on UAS

was not UAS 10600. According to the

10600 did not decrease.

longest mask matching rule, the packets

3. To know the contents of the broadcast

to 192.168.211.0/24 were forwarded to

packets, engineers connected a PC to the 8512

another device instead of UAS 10600.

switch and transmitted all VLANs to this port

Therefore, the user who obtained the IP

transparently. So engineers could get the broadcast

address 192.168.211.1/24 failed to get

packet contents through the PC. According to the

information in the packets, besides the proper

8. If the user disconnected the

broadcast packets, there was a user scanning (the

connection and dialed up again, according

traffic was very little). Therefore, the failure was not