ZXR105900ESeriesnova-minsk.com/ZTE/59E/SJ-20150114102049-012-ZXR10... · ZXR105900ESeries...

ZXR10 5900E SeriesEasy-Maintenance MPLS Routing Switch

Troubleshooting

Version: 3.00.11

ZTE CORPORATIONNo. 55, Hi-tech Road South, ShenZhen, P.R.ChinaPostcode: 518057Tel: +86-755-26771900Fax: +86-755-26770801URL: http://support.zte.com.cnE-mail: [email protected]

LEGAL INFORMATIONCopyright © 2014 ZTE CORPORATION.

The contents of this document are protected by copyright laws and international treaties. Any reproduction or

distribution of this document or any portion of this document, in any form by any means, without the prior written

consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by

contractual confidentiality obligations.

All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE

CORPORATION or of their respective owners.

This document is provided “as is”, and all express, implied, or statutory warranties, representations or conditions

are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,

title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the

use of or reliance on the information contained herein.

ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications

covering the subject matter of this document. Except as expressly provided in any written license between ZTE

CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter

herein.

ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.

Users may visit the ZTE technical support website http://support.zte.com.cn to inquire for related information.

The ultimate right to interpret this product resides in ZTE CORPORATION.

Revision History

Revision No. Revision Date Revision Reason

R1.0 2015-01-15 First edition

Serial Number: SJ-20150114102049-012

Publishing Date: 2015-01-15 (R1.0)

SJ-20150114102049-012|2015-01-15 (R1.0) ZTE Proprietary and Confidential

ContentsAbout This Manual ......................................................................................... I

Chapter 1 Troubleshooting Overview....................................................... 1-11.1 Fault Classification ............................................................................................. 1-1

1.1.1 Hardware Fault ........................................................................................ 1-1

1.1.2 Software Fault.......................................................................................... 1-2

1.2 Troubleshooting Methods.................................................................................... 1-2

1.3 Emergency Help ................................................................................................ 1-3

Chapter 2 Hardware Troubleshooting ...................................................... 2-12.1 Power Troubleshooting ....................................................................................... 2-1

2.2 Fans Troubleshooting ......................................................................................... 2-2

2.3 Ports Troubleshooting......................................................................................... 2-3

Chapter 3 Software Troubleshooting........................................................ 3-13.1 Troubleshooting Case: Ports Fail to Work in Link-up State .................................... 3-1

3.2 Troubleshooting Case: Some Packets are Lost during Traffic Forwarding overthe Link............................................................................................................ 3-5

3.3 Troubleshooting Case: STP Loop Storm.............................................................. 3-8

3.4 Troubleshooting Case: State of STP Topology Structure Keeps Fluctuating ......... 3-12

3.5 Troubleshooting Case: Multiple Devices Fail to Work Well Together in the SameMSTP Domain................................................................................................ 3-15

3.6 Troubleshooting Case: STP Designated Port is in a Continuous State ofDiscard .......................................................................................................... 3-19

3.7 Troubleshooting Case: ZESR Ring Network Fails to be in Up State ..................... 3-21

3.8 Troubleshooting Case: Dual Devices are in Master State in the VRRP BackupGroup ............................................................................................................ 3-24

3.9 Troubleshooting Case: VRRP Backup Group State Fluctuates Repeatedly .......... 3-28

3.10 Troubleshooting Case: ARP Learning Partly Fails ............................................ 3-31

3.11 Troubleshooting Case: IGMP Snooping User Fails to be Online......................... 3-35

3.12 Troubleshooting Case: The Program Fails to Play Smoothly When beingViewed by Users............................................................................................. 3-41

3.13 Troubleshooting Case: IPTV Users Fail to Use the VOD Function ..................... 3-43

3.14 Troubleshooting Case: IPTV Users Switch Offline Abnormally........................... 3-46

3.15 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address Whenbeing Connected to the DHCP Server Directly .................................................. 3-49

I


3.16 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCPSnooping ....................................................................................................... 3-53

3.17 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCPRelay ............................................................................................................. 3-57

3.18 Troubleshooting Case: Users of a Switch Fail to Receive Traffic in PIM_SMEnvironment................................................................................................... 3-60

3.19 Troubleshooting Case: RP Information is Wrong in PIM-SM Environment .......... 3-65

3.20 Troubleshooting Case: Source Fails to Register in PIM-SM Environment ........... 3-68

3.21 Troubleshooting Case: Anycast RP Works Abnormally in MSDP Environment..................................................................................................................... 3-73

3.22 Troubleshooting Case: System CPU Overload Alarm ....................................... 3-77

Figures............................................................................................................. I

Glossary ........................................................................................................ III

II


About This ManualPurposeThis manual is the ZXR10 5900E Series (V3.00.11) Easy-Maintenance MPLS RoutingSwitch Troubleshooting, which is applicable to the ZXR10 5900E (V3.00.11) seriesswitches.

Thismanual describes common problems associated with the ZXR10 5900ESeries switch,the relevant solutions and preventive measures.

Intended AudienceThis manual is intended for:

l Network maintenance engineersl Testing engineersl On-duty personnel

What Is in This ManualThis manual contains the following chapters:

Chapter 1, Troubleshooting

Overview

Introduces the fault classification and relevant troubleshooting methods.

Chapter 2, Hardware

Troubleshooting

Introduces the hardware faults associated with the ZXR10 5900E Series

switch, the relevant solutions and preventive measures.

Chapter 3, Software

Troubleshooting

Introduces the software faults associated with the ZXR10 5900E Series

switch, the relevant solutions and preventive measures.

ConventionsThis manual uses the following typographical conventions:

Italics Variables in commands. It may also refer to other related manuals and documents.

Bold Menus, menu options, function names, input fields, option button names, check boxes,

drop-down lists, dialog box names, window names, parameters, and commands.

Constant

width

Text that you type, program codes, filenames, directory names, and function names.

[ ] Optional parameters.

{ } Mandatory parameters.

| Separates individual parameters in a series of parameters.

{x|y|z} Mandatory alternative keywords are grouped in braces and separated by vertical bars.

I


[x{y|z}] Optional alternative keywords are grouped in brackets and separated by vertical bars

or braces.

{[x], [y], [z]} Mandatory alternative keywords are grouped in braces and separated by brackets

individually.

*(x) One or multiple xs.

Note: provides additional information about a certain topic.

II


Chapter 1Troubleshooting OverviewNetwork troubleshooting is performed based on knowledge about network principles,network configurations and network operation. It is an activity to repair a faulty network by1. Confirming fault symptoms.2. Obtaining diagnostic information through diagnostic tools.3. Locating the faulty point.4. Finding out the source of the fault.5. Removing the fault eventually.

Troubleshooting should focus on the following aspects:

l Locating the faulty point in the network to resume the normal operation of the networkl Finding out imperfections in network planning and configurations to improve and

optimize network performancel Observing the running status of the network to timely predict network communication

qualityl Summarizing troubleshooting experience in time to avoid similar faultsTable of Contents

Fault Classification .....................................................................................................1-1Troubleshooting Methods ...........................................................................................1-2Emergency Help.........................................................................................................1-3

1.1 Fault ClassificationSwitch faults are generally classified into hardware faults and software faults.

1.1.1 Hardware FaultThe hardware faults are service interruptions or poor performance caused by the hardwareof a switch, and can be classified into the following categories:

l Power supply fault

The switch fails to work properly when power supply modules are damaged or fansstop running due to an unstable external power supply, aging power circuitry orlighting.The power supply faults may cause damage to other components of theswitch.

l Fan fault

The fan status directly affects the heat dissipation and operation of the entire switch. Ifthe switch keeps working at an abnormal temperature for a long time, the performance

1-1


ZXR10 5900E Series Troubleshooting

of the switch can be degraded, service communication can be affected, and even thehardware may be damaged.

l Port fault

This is the most common hardware fault. Be careful when plugging in or unpluggingthe connector of a port, no matter the port is an optical fiber one or an RJ-45twisted-pair one. Otherwise, the port may fail, and communication is affected.

1.1.2 Software FaultThe software faults are the faults in the system or the configurations, and can be classifiedinto the following categories:

l System errorl Improper configurationl External factors

1.2 Troubleshooting MethodsThere are various switch faults, and each fault has its own symptoms. Use the appropriatemethods for different symtoms when analyzing faults, then locate the faulty point and solvethe problem in time.

l Exclusion

The exclusion method is to list all possible causes based on the observedfault symptoms, and then analyze and remove them one by one. Abide by thesimple-to-difficult principle to improve efficiency. This method is applicable to alltypes of faults. However, it requires that maintenance engineers should have stronglogical minds, and a full and deep understanding of the switch.

l Contrast

The contrast method is to locate the faulty point by contrasting the faulty switch andthe existing switches that are of the same type and work properly. This method issimple and effective, especially for the faults in system configurations. The differencein configurations can be easily found through simple observation.

l Substitution

The substitution method is the most common and most frequently used one in switchmaintenance. It is to locate the faulty point by substituting a normal component forthe component that is likely to malfunction. It is mainly used to diagnose hardwarefaults. Note that the substitute component and the faulty component must be exactlythe same in every respect such as the brand, model and the type of the switch thatthe component works in.

1-2


Chapter 1 Troubleshooting Overview

1.3 Emergency HelpRequest emergency help immediately if services cannot be recovered after the emergencyplan has been started and the troubleshooting measures have been taken, or if majorsystem faults occur. The emergency help channels provided by ZTE include a 7×24hotline, remote technical support and on-site technical support.

l Hotline

Dial the hotline of the ZTE Global Customer Support Center at 800-830-1118. Theservice fax number is (0755)26770801.

l Remote technical support

ZTE technicians can remotely log in to the site where the faults occur according tothe information provided by the hotline. ZTE technicians instruct customers over thephone to solve general problems. For complicated problems, ZTE sendsmaintenanceexperts to the site.

l On-site technical support

After reaching the site, the experts take emergency maintenance measures to restorecommunication as soon as possible.

1-3



This page intentionally left blank.

1-4


Chapter 2Hardware TroubleshootingFigure 2-1 shows the general procedure for hardware fault troubleshooting.

Figure 2-1 General Procedure for Hardware Fault Troubleshooting

Table of ContentsPower Troubleshooting...............................................................................................2-1Fans Troubleshooting.................................................................................................2-2Ports Troubleshooting ................................................................................................2-3

2.1 Power TroubleshootingFault DescriptionBased on the type of the device and the quantity of power supplies, the possible symptomsof a power supply fault may include the following:

l Power-off of the equipment.

2-1



l Off state of the POWER indicator on the panel.l Red state of the SYS/ALM indicator if there is no indicator for POWER.

Troubleshooting Steps and Preventive MeasuresCheck the device state and indicator state. Use the show power command to check thepower supply state.

For such problems, first make sure that the external power supply works properly.Generally, independent power lines are used to provide independent power supplies,and voltage regulators are used to prevent power surges. If conditions permit, theUninterruptable Power Supply (UPS) devices can be used to ensure the normal powersupply for the switches. When choosing the UPS devices, note that some UPS devicesprovide a voltage-stabilizing function, while some do not.

2.2 Fans TroubleshootingFault DescriptionBased on the type of the device and the quantity of power supplies, the possible symptomsof the fan fault include the following:

l The device overheats and fans fail to work properlyl The indicator for fans is red.l The SYS/ALM indicator is red when there is no indicator for fans.

Fan faults are commonly caused by the following:

l Power supply problems, which may cause insufficient voltage for fans, or over-highvoltage for fans to burn up.

l Accumulations of dust on fans, which affect the running of fans.l Problems of the motors of fans, which affect the running of fans.

Troubleshooting Steps and Preventive MeasuresSteps for troubleshooting fans are as follows:

1. Check the power supply state. If the voltage is abnormal, restore the power supply tonormal state.

2. If the power supply is normal, clean the fan and maintain the motors of fans.3. If the power indicator shows that the power supply is normal, but the fan does not run,

verify whether the wind force of the fan is normal.4. Use the show fan command to check the fan state.

For the above causes of fan faults, the following preventive measures can be taken:

1. Use voltage regulators, UPS, and lightning protection devices to ensure that the powersupply modules work normally.

2-2


Chapter 2 Hardware Troubleshooting

2. Clean and maintain fan modules regularly to avoid dust accumulation. Theaccumulation could cause the power consumption of the motors of fans to increase,which can affect the lifespan of fans.

3. Put lubricants on the motors of fans to help ensure that fans are in good condition.

2.3 Ports TroubleshootingFault DescriptionA port fault may involve one or multiple faulty ports. The faulty ports can be found bychanging the port that the PC is connected to if the PC has been verified to be normal.

Troubleshooting Steps and Preventive MeasuresFor such faults, power off the switch and then clean the faulty port with alcohol cotton.Ifthe service still cannot be recovered, the port is verified to be damaged. Change the portor the entire device. Pay attention to the following aspects when conducting the operation:

l When moving devices, avoid unexpected collision, which may cause damage to thehardware of fans.

l The port may be destroyed when the cable connector with a larger dimension isplugged into it.

l If a part of the twisted-pair that connects a port is installed outdoors and the cableis struck by lightning, the port may be damaged and there might be even moreunexpected damages.

2-3



This page intentionally left blank.

2-4


Chapter 3Software TroubleshootingTable of Contents

Troubleshooting Case: Ports Fail to Work in Link-up State .........................................3-1Troubleshooting Case: Some Packets are Lost during Traffic Forwarding over theLink ............................................................................................................................3-5Troubleshooting Case: STP Loop Storm ....................................................................3-8Troubleshooting Case: State of STP Topology Structure Keeps Fluctuating .............3-12Troubleshooting Case: Multiple Devices Fail to Work Well Together in the SameMSTP Domain..........................................................................................................3-15Troubleshooting Case: STP Designated Port is in a Continuous State of Discard.....3-19Troubleshooting Case: ZESR Ring Network Fails to be in Up State .........................3-21Troubleshooting Case: Dual Devices are in Master State in the VRRP BackupGroup.......................................................................................................................3-24Troubleshooting Case: VRRP Backup Group State Fluctuates Repeatedly ..............3-28Troubleshooting Case: ARP Learning Partly Fails ....................................................3-31Troubleshooting Case: IGMP Snooping User Fails to be Online...............................3-35Troubleshooting Case: The Program Fails to Play Smoothly When being Viewedby Users...................................................................................................................3-41Troubleshooting Case: IPTV Users Fail to Use the VOD Function............................3-43Troubleshooting Case: IPTV Users Switch Offline Abnormally .................................3-46Troubleshooting Case: DHCP Client Fails to Obtain an IP Address When beingConnected to the DHCP Server Directly ...................................................................3-49Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCPSnooping..................................................................................................................3-53Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCPRelay........................................................................................................................3-57Troubleshooting Case: Users of a Switch Fail to Receive Traffic in PIM_SMEnvironment.............................................................................................................3-60Troubleshooting Case: RP Information is Wrong in PIM-SM Environment ................3-65Troubleshooting Case: Source Fails to Register in PIM-SM Environment.................3-68Troubleshooting Case: Anycast RP Works Abnormally in MSDP Environment ........3-73Troubleshooting Case: System CPU Overload Alarm...............................................3-77

3.1 Troubleshooting Case: Ports Fail to Work inLink-up State

Figure 3-1 shows that PORT 1 and PORT 2 fail to work in link-up state after beingconnected through a network cable or optical fiber cable.

3-1



Figure 3-1 Troubleshooting Case: Ports Fail to Work in Link-up State

Figure 3-2 shows the troubleshooting procedure for the case that ports fail to work in link-upstate.

Figure 3-2 Troubleshooting Procedure Diagram for the Case that Ports Fail to Work inLink-up State

Steps1. Check the quality of the network cable or optical fiber cable, and whether the TX and

RX connections of the optical fiber cables are correct.

Poor quality of the network cable or the optical fiber cable is a common cause of thelink-up failure. Such problems can be eliminated by substituting a new and high-qualitycable for the old one. If PORT 1 and PORT 2 are Ethernet optical ports, the TX andRX connections of the optical fiber cable must be verified to be correct, that is, the TXof the local end must connect the RX of the peer end and the RX of the local end mustconnect the TX of the peer end.

2. Check whether the properties and configurations of the local port are consistent withthose of the peer port.

3-2


Chapter 3 Software Troubleshooting

Disagreement between the speed properties of the two ports may cause the link-upfailure.

Ethernet electrical ports can work in the link-up state successfully only after they areconfigured according to the following pairs.(GE indicates gigabit ethernet port; FEindicates 100-megabit ethernet port.)

Port Configurations of Ethernet Electrical Ports Negotiation Result

PORT 1 PORT 2 PORT 1 PORT 2

GE negotiation auto GE negotiation auto 1000M/Full 1000M/Full

GE negotiation auto FE negotiation auto 100M/Full 100M/Full

FE negotiation auto FE negotiation auto 100M/Full 100M/Full

GE

no negotiation auto

speed 100

duplex full(default)

FE

no negotiation auto

speed 100(default)


100M/Full 100M/Full

The ethernet optical port doesn't support the auto-negotiation of rate and duplex mode,so each of the following properties of the interconnected ports must be the same: rate,duplex mode, and model of the optical module ( SFP or SFP+ ).

Port Configurations of Ethernet Optical Ports Negotiation Result


GE negotiation auto GE negotiation auto 1000M/Full 1000M/Full

GE no negotiation auto


GE no negotiation auto


1000M/Full 1000M/Full

10GE negotiation auto 10GE negotiation auto 10000M/Full 10000M/Full

10GE no negotiation auto


10GE no negotiation auto


10000M/Full 10000M/Full

a. Use the show interface command to check the current propertiesof a port. "electric " indicates that it is an ethernet electrical port. "BW 1000000Kbits " indicates that it works at the rate of 1000Mbps.ZXR10(config)#show interface gei-0/1/1/1

gei-0/1/1/1 is down, line protocol is down ,IPv4 protocol is down, IPv6 protocol

is do

Description is none

Hardware is Gigabit Ethernet, address is 00e0.d122.1000

BW 1000000 Kbps

MTU 1600 bytes

The port is electric

Duplex full

Negotiation auto

3-3



Mdi type:auto

Last Clear Time : 2010-01-01 00:02:02 Last Refresh Time: 2010-01-01 19:10:30

120s input rate : 0Bps 0Pps

120s output rate: 0Bps 0Pps

b. Use the show running-config eth-port [all] command to check the currentconfiguration of a port. Auto-negotiation is enabled by default for the ports of theZXR10 5900E. (Contents with the "#" mark are the default configurations.)ZXR10(config-if-gei-0/1/1/1)#show running-config eth-port

!

interface gei-0/1/1/1

broadcast-limit percent 10

multicast-limit percent 100

unknowncast-limit percent 10

!

ZXR10(config-if-gei-0/1/1/1)#show running-config eth-port all

!


eee disable

#port-bridge disable

#hybrid-attribute copper

#optical-inform monitor disable

negotiation auto

#duplex full

#cable-media mode auto

#flowcontrol disable

#master-slave mode auto

#jumbo-frame disable

port-hold time 0

#broadcast-limit percent 10

#multicast-limit percent 100

#unknowncast-limit percent 10

#wan-mode disable

!

c. Use the show optical-inform interface command to check the DOM information ofthe optical module on PORT 1 and PORT 2. Make sure that the information ofthe optical module on PORT 1 is the same as that on PORT 2. The informationincludes "Type" and "Length" (The DOM function is disabled by default for theports of the ZXR10 5900E. The function can be enabled by optical-informmonitor enable.)ZXR10(config)#show optical-inform interface xgei-0/1/2/1

Portname Online EtherProperty Vendor VendorPN VendorSN Type Length

WaveLen (single) (OM2) (OM1) (OM3) (copper)

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

3-4



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

xgei-0/1/2/1 SFP+ 10GBASE-LR FINISAR CORP. FTLX1471D3BCL AP101BT single

100km N/A N/A N/A N/A 1310nm

3. Check whether PORT 1, PORT 2, and their optical modules (if they are optical ports)are damaged.

All the optical modules and ethernet ports are required to be checked if the problemstill cannot be solved after all the above factors have been verified to be alright. Thestate of an optical module can be verified by the single-port loopback method. Thestate of an ethernet port can be verified by the substitution method; An available idleport can be substituted for the port to be checked.

– End of Steps –

3.2 Troubleshooting Case: Some Packets are Lostduring Traffic Forwarding over the Link

Figure 3-3 shows that there are lost packets in the traffic from PORT 1 to PORT 2 in thistopology structure.

Figure 3-3 Troubleshooting for Lost Packets during Traffic Forwarding over the Link

Figure 3-4 shows the troubleshooting procedure for lost packets during flow forwardingover the link.

Figure 3-4 Troubleshooting Procedure Diagram for Lost Packets during FlowForwarding over the Link

3-5



Steps1. Check whether the port property is half-duplex.

If the duplex property of either of the two interconnected ports is half-duplex, there willbe a unidirectional link between the two ports. The relation between port configurationpair and negotiation result is shown in the list below.

Port Configuration Pair Negotiation Result


negotiation auto negotiation auto full full

negotiation auto no negotiation auto

duplex full

half full

negotiation auto no negotiation auto

duplex half

half half

no negotiation auto duplex

full

no negotiation auto

duplex full

full full


full

no negotiation auto

duplex half

full half


half

no negotiation auto

duplex full

half full


half

no negotiation auto

duplex full

half half

The first pair is recommended. If the negotiation fails and the ports fail to work inLink-up state, the fourth pair can be used. (Note that an electrical port with the rate of1000Mbps does not suport this pair.) No other pairs are recommended.

a. Use the show interface command to check the current propertiesof a port. "Duplex full" indicates the port is working in full-duplex state. (half forhalf-deplex state), "BW 1000000 Kbits" indicates the port is working at the rate of1000Mbps.ZXR10(config)#show interface gei-0/1/1/1

gei-0/1/1/1 is down, line protocol is down ,IPv4 protocol is down, IPv6 protocol

is do

Description is none


BW 1000000 Kbps

MTU 1600 bytes


Duplex full

Negotiation auto

Mdi type:auto



3-6




b. Use the show running-config eth-port [all] command to check the currentconfiguration of a port. Auto-negotiation is enabled by default for the ZXR105900E ports. (Contents with the "#" mark are the default configurations.)ZXR10(config-if-gei-0/1/1/1)#show running-config eth-port all

!


eee disable

#port-bridge disable

#hybrid-attribute copper

#optical-inform monitor disable

negotiation auto

#duplex full

#cable-media mode auto

#flowcontrol disable

#master-slave mode auto

#jumbo-frame disable

port-hold time 0

#broadcast-limit percent 10

#multicast-limit percent 100

#unknowncast-limit percent 10

#wan-mode disable

2. Check reports on the received and transmitted packets of a port to see whether thereare errors that have been recorded by the counters.

After ensuring that both of the two interconnect ports work in full-deplex state, usethe show interface command to check the reports on the received and transmittedpackets of the ports. For counter "CRC-ERROR", "Dropped", " Fragments", "Jabber"and " MacRxErr", a non-zero value for one or more of them indicates that the linkcommnunication of the port is of poor quality. The corresponding cable or port shouldbe changed.

For counter Undersize" and "Oversize", the ZXR10 5900E can forward packets withthe length ranging from 64 to 1560 bytes by default. The packet whose length issmaller than 64 bytes will be discarded and recorded by Undersize". The packetwhose length is larger than 1560 bytes will be discarded and recorded by " Oversize".If "jumble frame enable " is configured on the port, the packets whose length doesexceed the configured size can be restored by "Oversize".

ZXR10#show interface gei-0/1/1/1

gei-0/1/1/1 is administratively down, line protocol is down, IPv4 protocol is down,

IPv6 protocol is down


BW 1000000 Kbps

MTU 1600 bytes


3-7



Duplex full

Negotiation auto

Mdi type:auto




Peak rate:

input 0Bps peak time N/A

output 0Bps peak time N/A

Intf utilization: input 0% output 0%

HardWareCounters:

In_Bytes 0 In_Packets 0

In_Unicasts 0 In_Broadcasts 0

In_Multicasts 0 In_Undersize 0

In_CRC_ERROR 0 In_DropEvents 0

In_Fragments 0 In_Jabbers 0

In_MacRxError 0 In_64B 0

In_65_127B 0 In_128_255B 0

In_256_511B 0 In_512_1023B 0

In_1024_1518B 0 In_Oversize 0

E_Bytes 0 E_Packets 0

E_Unicasts 0 E_Broadcasts 0

E_Multicasts 0 E_SingCollision 0

E_LateCollision 0 E_64B 0

E_65_127B 0 E_128_255B 0

E_256_511B 0 E_512_1023B 0

E_1024_1518B 0 E_Oversize 0


3.3 Troubleshooting Case: STP Loop StormFigure 3-5 shows that Switch B does not abide by the STP protocol to block PORT 3 inthis STP (Spanning Tree Protocol) ring networking scenario, so loop storm occurs amongthe six ports in the ring.

3-8



Figure 3-5 Troubleshooting STP Loop Storm

Figure 3-6 shows the troubleshooting procedure for STP loop storm.

Figure 3-6 Troubleshooting Procedure Diagram for STP Loop Storm

Steps1. Check whether STP is enabled globally.

3-9



STP is disabled globally by default. Use the show spantree instance 0 commandto check whether global STP is enabled. If no, configure spantree enable in globalconfiguration mode to enable STP.

ZXR10(config)#show spantree instance 0

%Info 11201: STP is disabled!

ZXR10(config)#spantree

ZXR10(config-stp)#enable

2. Check whether STP is enabled on all the interconnected ports in the ring.STP is enabled on ports by default.

Use the show spantree interface command to check whether STP isenabled on the node. If no, that is, The port is STP disabled! , configure spantreeenable in port configuration mode to enable STP.

ZXR10(config)#show spantree interface gei-0/1/1/5

Mst Instance Prio.Nbr

Name Port ID Cost Sts Role

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

MST00 128.1 N/A N/A NON_STP

ZXR10(config)#show spantree interface gei-0/1/1/5

%Info 11235: The port is STP disable


ZXR10(config-stp)#interface gei-0/1/1/5

ZXR10(config-stp-if-gei-0/1/1/5)#enable

ZXR10(config-stp-if-gei-0/1/1/5)#show spantree interface gei-0/1/1/5

Mst Instance Prio.Nbr

Name Port ID Cost State Role

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

MST00 128.3 20000 Forward Designated

3. Check whether STP packets on all ports are of the same type.

The default MSTP packet format of the ZXR10 5900E ports is the standard IEEEformat. The private format of CISCO, HAMMER and HUAWEI is also supported. Forall nodes, the standard IEEE type is recommended. Packet format can be changedas follows:



ZXR10(config-stp-if-gei-0/1/1/5)#packet-type ?

cisco STP CISCO packet-type

hammer STP HAMMER packet-type

huawei STP HUAWEI packet-type

ieee STP IEEE packet-type

3-10



ZXR10 (config-stp-if-gei-0/1/1/5)#packet-type ieee

4. Check whether BPDU packets can be received and transmitted normally among theinterconnected ports in the ring.

Use the debug spantree {bpdu-rx | bpdu-tx} interface command tocheck the debugging messages about how a specified port receives and transmitsBPDU packets.

Note:

After locating the problem, do execute the no debug all command to disable debuggingmode. Otherwise, long-time debugging can occupy excessive system resources.

For equipment in the existing networking, never execute the debug all command toenable all debugging switches.

If the BPDU-TX of the peer end has sent printed log, but the BPDU-RX of the localend fails to receive the printed log within a specified period, it indicates that theremay be lost packets when packets are being forwarded over the link. Refer to "3.2Troubleshooting Case: SomePackets are Lost during Traffic Forwarding over the Link"to locate the problem.

If the BPDU-RX of the local end successfully receives the printed log, but the state ofSTP of the port is still incorrect, collect the printed logs of the show spantree mst-configcommand and the show spantree interface command and the debug spantree {bpdu-rx | bpdu-tx} interface command, and then seektechnical support.

ZXR10#ZXR10 MP-0/1/0 2010-1-1 20:00:36 STP: tx config bpdu from port gei-0/1/1/2

ZXR10 MP-0/1/0 2010-1-1 20:00:36 01 80 C2 00 00 00 00 D0 D2 55 10 00 00 26 42 42

03 00 00 00 00 00 10 00 00 D0 D0 61 10 00 00 00

00 00 10 00 00 D0 D0 61 10 00 80 03 00 00 14 00

02 00 0F 00

ZXR10 MP-0/1/0 2010-1-1 20:00:38 STP: tx config bpdu from port gei-0/1/1/2

ZXR10 MP-0/1/0 2010-1-1 20:00:38 01 80 C2 00 00 00 00 D0 D2 55 10 00 00 26 42 42

03 00 00 00 00 00 10 00 00 D0 D0 61 10 00 00 00

00 00 10 00 00 D0 D0 61 10 00 80 03 00 00 14 00

02 00 0F 00

ZXR10#no debug all


3-11



3.4 Troubleshooting Case: State of STP TopologyStructure Keeps Fluctuating

There are continual error log messages about state fluctuation in the STP topologystructure as shown below.

UTC alarm 24326 occurred %STP% port instance topology

detected. sent by MCP

UTC alarm 24326 occurred %STP% mst: role recompute instance sent by MCP

Figure 3-7 shows the troubleshooting procedure for continual state fluctuation in STPtopology structure.

Figure 3-7 Troubleshooting Procedure Diagram for Continual State Fluctuation in STP TopologyStructure

3-12



Steps1. Check whether the state of STP on the port fluctuates.

If there are continual error log messages about state fluctuation in STP on the port asfollows, it indicates that there may be link fault on the port.

11:05:13 10/19/2012 UTC alarm 24326 occurred %STP% port gei-0/1/1/2 instance 0 state

changed disabled->discard. sent by MCP


changed discard->learn. sent by MCP


changed learn->forward sent by MCP

11:05:43 10/19/2012 UTC alarm 24326 occurred %STP% port gei-0/1/1/2 instance 0 topology

detected. sent by MCP

Check whether the physical link of the port is unstable upon the above error log. Usethe show interface command to check the time point when the portlast worked in up/down state.

ZXR10(config)#show interface gei-0/1/1/2

gei-0/1/1/2 is up, line protocol is up, IPv4 protocol is up, IPv6 protocol is down

Hardware is Gigabit Ethernet, address is 00d0.d255.1000

BW 1000000 Kbps

MTU 1600 bytes


Duplex half

No negotiation auto

Mdi type:auto




Peak rate:

input 138Bps peak time 2010-01-01 04:23:30

output 98Bps peak time 2010-01-01 05:01:40

Intf utilization: input 0% output 0%

HardWareCounters:

In_Bytes 427364007185 In_Packets 1669399056

In_Unicasts 0 In_Broadcasts 0

In_Multicasts 1669399056 In_Undersize 0

In_CRC_ERROR 0 In_DropEvents 156

In_Fragments 0 In_Jabbers 0

In_MacRxError 0 In_64B 13

In_65_127B 49 In_128_255B 496331

In_256_511B 1668902663 In_512_1023B 0

In_1024_1518B 0 In_Oversize 0

E_Bytes 427250868630 E_Packets 1668963964

E_Unicasts 0 E_Broadcasts 0

3-13



E_Multicasts 1668963964 E_SingCollision 0

E_LateCollision 0 E_64B 3587

E_65_127B 2 E_128_255B 49717

E_256_511B 1668910658 E_512_1023B 0

E_1024_1518B 0 E_Oversize 0

2. Check whether the state of STP on the port ages.

a. The error log message about the aged state of STP on the port is as follows. Makesure that, for all equipment in the network, the value of BPDU packet sending cycle(Hello-Time) is the same as that of expiration time (Max-Age). Otherwise, the stateof STP on the port may get aged.1/05/2012 UTC alarm 24326 occurred %STP% mst: role recompute instance 0

due to port gei_0/1/1/2 aged sent by MCP

Note:

For the ZXR10 5900E, the default values of STP's Hello-time and Max-Age are2 seconds and 20 seconds, respectively. Use the show spanning-tree instance 0command to check the value of Hello-time and Max-Age that are configured forthe current root bridge and the specified bridge.


MST00

Spanning tree enabled protocol MSTP

Root ID: Priority 32768; Address 00d0.d059.6030

Hello-Time 2 sec; Max-Age 20 sec

Forward-Delay 15 sec;

RegRootID: Priority 32768; Address 00d0.d059.6030

BridgeID: Priority 32768; Address 00d0.d059.6030


Forward-Delay 15 sec; Max-Hops 20

Message-Age 0 sec; RemainHops 20

b. If the problem still cannot be solved after the Hello-Time and Max-Age of BPDUpackets of all equipment nodes are verified to be the same, check whether theBPDU packets over the link can be transmitted and received successfully.

Use the debug spantree {bpdu-rx | bpdu-tx} interface commandto check the debugging messages about how a specified port receives andtransmittes the BPDU packets.

3-14



Note:

After locating the problem, do execute the no debug all command to disabledebugging mode. Otherwise, long-time debugging can occupy excessive systemresources.

For equipment in the existing networking, never execute the debug all commandto enable all debugging switches.

If the BPDU-TX of the peer end has sent printed log, but the BPDU-RX of the localend fails to receive the printed log within a specified period, it indicates that theremay be lost packets when packets are being forwarded over the link. Refer to "3.2Troubleshooting Case: Some Packets are Lost during Traffic Forwarding over theLink" to locate the problem.

If the BPDU-RX of the local end successfully receives the printed log, but the stateof STP of the port is still incorrect, collect the printed logs of the show spantreemst-config command, the show spantree interface command andthe debug spantree {bpdu-rx | bpdu-tx} interface command, andthen seek technical support.

STP transmitted BPDUs interface gei-0/1/1/2 debugging is on

ZXR10#ZXR10 MP-0/1/0 2010-1-1 20:00:36 STP: tx config bpdu from port gei-0/1/1/2

ZXR10 MP-0/1/0 2010-1-1 20:00:36 01 80 C2 00 00 00 00 D0 D2 55 10 00 00 26 42 42

03 00 00 00 00 00 10 00 00 D0 D0 61 10 00 00 00

00 00 10 00 00 D0 D0 61 10 00 80 03 00 00 14 00

02 00 0F 00

ZXR10 MP-0/1/0 2010-1-1 20:00:38 STP: tx config bpdu from port gei-0/1/1/2

ZXR10 MP-0/1/0 2010-1-1 20:00:38 01 80 C2 00 00 00 00 D0 D2 55 10 00 00 26 42 42

03 00 00 00 00 00 10 00 00 D0 D0 61 10 00 00 00

00 00 10 00 00 D0 D0 61 10 00 80 03 00 00 14 00

02 00 0F 00 ZXR10#no debug all


3.5 Troubleshooting Case: Multiple Devices Fail toWork Well Together in the Same MSTP Domain

Figure 3-8 shows that the devices in the ring fail to work well together in the same MSTPafter MSTP is deployed in the ring network. (The result of the show spantree instance command shows that the root port works in Master state in multiple instances.)

3-15



Figure 3-8 Troubleshooting Case: Multiple Devices Fail to Work Well Together in theSame MSTP Domain

Figure 3-9 shows the troubleshooting procedure for the case that multiple devices fail towork well together in the Same MSTP domain.

Figure 3-9 Troubleshooting Procedure Diagram for the Case that Multiple Devices Failto Work Well Together in the Same MSTP Domain

Steps1. Check whether the STP running on the devices works in MSTP mode.

3-16



Use the show spantree mst-config command to check the current running mode of STP.If it is not MSTP, use the spantree mode mstp command to modify the mode to MSTP.(The default STP mode of the ZXR10 5900E is MSTP.)

ZXR10(config)#show spantree mst-config

spanning-tree mode: [RSTP]


ZXR10(config-stp)#spantree mode mstp

ZXR10(config)#show spantree mst-config

spanning-tree mode: [MSTP]

CISCO Hmd5-key : 0x13ac06a62e47fd51f95d2ba243cd0346

CISCO Hmd5-digest : 0x00000000000000000000000000000000

HUAWEI Hmd5-key : 0x13ac06a62e47fd51f95d2ba243cd0346

HUAWEI Hmd5-digest : 0x00000000000000000000000000000000

Name : [00d0d0596030]

Revision : 0

Instance Vlans mapped

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

0 1-4094

2. Check the consistency in the summary of each MSTP configuration.

All MSTP bridge devices in the same MSTP domain should meet the following threeconditions:

l All devices should have the same Name (domain name).l All devices should have the same Revision (version level).l All devices should have the same mapping relationship between instance and

VLAN.

a. The method for modifying Name.

For the ZXR10 5900E, the default MSTP Name is the device's system MAC. Usethe name command in MSTP configuration mode to modify the name.


ZXR10(config-stp)#mst name zte

ZXR10(config-stp)#show spantree mst

spantree mode: [MSTP]





Name : [zte]

Revision : 0


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

0 1-4094

3-17



ZXR10(config-mstp)#

b. The method for modifying Revision.

For the ZXR10 5900E, the default MSTP Revision is 0. Use the revision commandin MSTP configuration mode to modify it.


ZXR10(config-stp)#mst revision ?

Revision

ZXR10(config-stp)#mst revision

c. The method for modifying the mapping relationship between instance and VLAN.

For the ZXR10 5900E, the default MSTP mapping relationship between instanceand VLAN is that all VLANs belong to instance 0. Use the mst vlans instance command to modify it.

ZXR10(config-stp)#show spantree mst

spanning-tree mode: [MSTP]





Name : [00d0d0596030]

Revision : 0


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

0 1-4094


ZXR10(config-stp)#mst vlans ?

VLAN id or VLAN rang

ZXR10(config-stp)#mst vlans 100 instance ?

Instance ID

3. Check whether STP packets on all ports are of the same type.

The default MSTP packet format of the ZXR10 5900E ports is of standard IEEE type.The private format of CISCO, HAMMER and HUAWEI is also supported. For all nodes,the standard IEEE type is recommended. Packet format can be changed as follows.


ZXR10(config-stp-if-gei-0/1/1/2)#packet-type ?

CISCO Spanning-tree CISCO packet-type

HAMMER Spanning-tree HAMMER packet-type

HUAWEI Spanning-tree HUAWEI packet-type

IEEE Spanning-tree IEEE packet-type

ZXR10(config-stp-if-gei-0/1/1/2)#packet-type IEEE


3-18



3.6 Troubleshooting Case: STP Designated Port is in aContinuous State of Discard

The port whose STP role is Designated is in a continuous state of Discard * (the normalstate of a blocked port is "Discatd" without "*".), and fails to complete the state changefrom discard to learn, and eventually to forward.


MST01

Spantree enabled protocol MSTP

RegRootID: Priority 1; Address 0022.9354.f8f8


Forward-Delay 15 sec;

BridgeID: Priority 32769; Address 00d0.d0c0.0000


Forward-Delay 15 sec; Max-Hops 20

Message-Age 0 sec; RemainHops 19

Interface Prio.Nbr

Name Port ID Cost Sts Role Type Bound

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

gei_0/1/1/1 128.2 20000 Forward Root p2p MSTP

xgei_0/1/1/2 128.3 2000 Discard* Designated p2p MSTP

Figure 3-10 shows the troubleshooting procedure for the case that STP designated port isin a continuous state of discard *.

3-19



Figure 3-10 Troubleshooting Procedure Diagram for the Case that STP Designated Port is in aContinuous State of Discard *

Steps1. Check whether root guard is enabled on the port.

The STP root guard funcation provides a way to protect the root bridge. If a new switchwhose bridge ID is lower than that of the current root bridge accesses the network afterthe network completes the spanning tree calculation, the new bridge will take over therole of the root bridge, which can cause the network to recalculate the spanning tree.To avoid such problems, root guard can be enabled on the port of the new device viawhich the device accesses the network. If the bridge receives Bridge Protocol DataUnits (BPDUs) with lower bridge ID on a root guard-enabled port, root guard movesthis port to a root-inconsistent STP state. Once the bridge stops receiving BPDUswith lower bridge ID, the port will go from the listening state to the learning state, andeventually switch to the forwarding state.

The root port does receive BPDU from the peer when the topology structure is stable.Therefore, if root gurad is wrongly enabled on the root port, the root port will switchto the designated port and be in a blocking state of "Discard *", and the entire STPtopology structure will be recalculated as well.

If there is "13:27:11 04/15/2007 UTC alarm 24322 occurred %STP%SPANTREE-ROOTGUARD_BLOCK: Root guard blocking port gei_0/1/1/1 instance 0

3-20



sent by MCP" in the error log, it indicates that root guard is enabled on the port andthe port has received attack from BPDU with a lower bridge ID. Check whether rootguard is wrongly enabled on the port that needs to participate in the STP calculation.Ifthe configuration is verified to be wrong, disable the root guard on the port, otherwiselocate the source of the outer BPDU attack and then eliminate it.

2. Check whether loop guard is enabled on the port.

Loop guard is to avoid loop storm caused by the STP error that occurs when theblocked port fails to receive the BPDU packets due to unidirectional communication.when a blocked port fails to receive the BPDU packets because of unidirectionalcommunication, STP moves the blocking port to a forwarding state, which leads toa loop. The problem can be solved by configuring loop guard on the port. For theblocked port on which loop guard is enabled, it enters the LOOP_INCONSISTENTstate if it does not receive BPDU packets any longer. No traffic is forwarded acrossthis port. The port automatically returns to the BLOCK state once it receives BPDUsagain.

Designated ports do receive the BPDUs from the peer when the topology structureis stable, so loop guard cannot be enabled on designated ports. Otherwise, thedesignated ports will be in the blocking state of "Discard *".

If there is "13:39:54 04/18/2007 UTC alarm 24320 occurred %STP%SPANTREE-LOOPGUARD_BLOCK: Loop guard blocking port xgei_0/1/1/2 instance1 sent by MCP" in the error log, it indicates that loop guard is enabled on the portand the port doesn't receive the BPDUs from the peer. Check whether loop guardis wrongly enabled on the port that needs to participate in the STP calculation.If theconfiguration is verified to be wrong, disable the loop guard on the port. Otherwise,locate the source of the outer BPDU attack and then eliminate it.


3.7 Troubleshooting Case: ZESR Ring Network Fails tobe in Up State

Figure 3-11 shows that the ZESR ring network fails to be in up state after being configured.

3-21



Figure 3-11 ZESR Ring Network Fails to be in Up State

Figure 3-12 shows the troubleshooting procedure for the case that ZESR ring network failsto be in up state.

Figure 3-12 Troubleshooting Procedure Diagram for the Case that ZESR Ring NetworkFails to be in Up State

3-22



Steps1. Check whether ZESR is configured on the right port.

The ZESRmisconfigurations on ports in the ring network can cause the ring network tofail to be in up state.Use the show zesr brief command to check the ZESR configurationon each device to see whether it is configured on the right port. If no, reconfigure it.

ZXR10(config)#show zesr brief

ctrl-vlan: 1000 protect-instance: 1 snoop-vpls:: enable

level seg role port port level-state switch-times

major master gei_0/1/1/1(P) gei_0/1/1/2(S) up 5

2. Check whether the state of each port in the ring is up.

Use the show interface brief command to check whether each port in the ring is in upstate.If no, refer to "3.1 Troubleshooting Case: Ports Fail to Work in Link-up State" tohandle the problem.

ZXR10(config)#show interface brief

Interface portattribute mode BW(Mbits) Admin Phy Prot Description

gei_0/1/1/1 electric Duplex/full 1000 up up up none

gei_0/1/1/2 electric Duplex/full 1000 up up up none

3. Check whether the role of each node is configured correctly.

If all ZESR nodes are configured as transit nodes, that is, there is no master node inthe ring, no nodes in the ring can receive the flash-up packet from the master node. Inthis way, the ZESR ring network fails to be in up state.Use the show zesr brief commandto check the role of each ZESR node configured on each device to see whether it isconsistent with that in the networking planning and whether there is one master node.Ifthere isn't a master node, reconfigure it.

ZXR10(config)#show zesr brief

ctrl-vlan: 1000 protect-instance: 1 snoop-vpls:: en able

level seg role port port level-state switch-times

major master gei_0/1/1/1(P) gei_0/1/1/2(S) up 5

4. Check whether the link-hello function is configured.

If the link-hello function is configured on ports in the ZESR ring, ensure that link-hellofunction is enable or disable at the same time on each interconnected port. Otherwise,the ZESR ring network may fail to be in up state.

Use the show zesr port-mode comnmand to check the link-hello configuration on eachport of the device in the ring.If the port is in "special" mode, it indicates that thelink-hello function is enabled on the port. If the port is in "normal" mode, it indicatesthat the function is disabled. If the function is enabled on a port, verify that it is alsoenabled on the peer port. The configured hello-interval should be verified to be thesame on both ports. So are the fail-times configurations.

ZXR10(config)#show zesr port-mode

Interface Link-hello Link-degrade Count

3-23



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

gei_0/1/1/2 normal N/A N/A

gei_0/1/1/1 special N/A N/A


3.8 Troubleshooting Case: Dual Devices are in MasterState in the VRRP Backup Group

Figure 3-13 shows that, in the normal situation, there is only one device that is in masterstate in the VRRP (Virtual Router Redundancy Protocol) backup group and all the otherdevices are in backup state. Multiple devices in master state can cause the hosts in theLAN to fail to communicate with the outside.

Figure 3-13 VRRP Networking

Figure 3-14 shows the troubleshooting procedure for dual masters in the VRRP backupgroup.

3-24



Figure 3-14 Troubleshooting Procedure Diagram for the Case that Dual Devices are in Master Statein the VRRP Backup Group

Steps1. Check whether the VRRP configuration of one device is consistent with that of the

other.

Use the show running-config vrrp command to check whether the backup groupconfiguration of one device is consistent with that of the other. The configurationsthat should be the same on both ends include VRID, authentication string, virtualIP address. And the IP addresses of the interfaces should be in the same networksegment. Use the show vrrp interface command to check whetherconfigurations of VRRP mode, preemption delay on both ends are the same.

ZXR10(config)#show running-config vrrp

!

vrrp

interface vlan 200

vrrp 1 accept

3-25



vrrp 1 ipv4 100.1.1.100

vrrp 1 priority 101

vrrp 1 version 2

!

end

ZXR10(config)#show vrrp interface vlan 200

vlan200 - Group 1

State is Master, Mode is Standard

Version is 2

Connection interface is vlan200

Virtual IP address is 100.1.1.100

Virtual MAC address is 0000.5e00.0101

Advertisement interval config is 1.000 sec

Preemption is enabled ,min delay is 0.000 sec

Priority is 100 (config 100)

Authentication is enabled

Track object 1 decrement 50 (up)

Master router is 100.1.1.1 (local), priority is 100

Master advertisement interval is 1.000 sec

Master down interval is 3.531 sec

2. Check whether the ping succeeds between interfaces where the VRRP backup groupis configured.

Ping the real IP address of the peer interface from the local interface. If the ping fails,follow the check below.

a. Verify that the ports that connect the VRRP link are correctly connected and inlink-up state. Otherwise, the port cannot send or receive VRRP advertisements.Simply observe the link indicators of both ports and use the show interface command to check whether the line protocol is in up state. Refer to"3.1 Troubleshooting Case: Ports Fail to Work in Link-up State" for the detailedtroubleshooting procedure.

b. Verify that the ports' VLAN properties are configured correctly. Use the show running-config vrrp command and the show vlan id command to check thecurrent configuration of the port and the port members in the VLAN. Ensure thatthe ports are configured in the corresponding VLAN correctly.ZXR10(config)#show interface gei_0/1/1/1

gei_0/1/1/1 is up, line protocol is up

Description is none


Duplex full

Mdi type:auto

MTU 1500 bytes BW 1000000 Kbits

ZXR10(config)#show running-config interface gei_0/1/1/1

Building configuration...

3-26



!

interface gei_0/1/1/1

out_index 6

eee enable

switchport mode trunk

switchport trunk native vlan 200

switchport trunk vlan 200

!

end

ZXR10(config)#show vlan id 200

VLAN Name Status Said MTU IsDynamic PvidPorts UntagPorts TagPorts

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

1 VLAN0001 NO gei_0/1/1/3-24

100 VLAN0100 NO gei_0/1/1/2 gei_0/1/1/2

200 VLAN0200 NO gei_0/1/1/1 gei_0/1/1/1

3. Check whether the backup group with lower priority receives illegal VRRPadvertisements.

Use the debug vrrp packet vrid command to check whether the backup groupwith lower priority receives illegal VRRP advertisements.

l If no, verify that the VLAN properties of the Layer 2 devices where VRRP runs areconfigured correctly.

l If yes, capture packets through the mirror port to check whether the receivedVRRP advertisements are valid.

l If illegal, collect the printed log messagees of debug vrrp error / event/state groupX and seek technical support.

ZXR10#debug vrrp packet group 1

VRRP group 1 packet debugging is on

01:27:16: VRRP: Interface vlan200 Grp 1 sending Advertisement

01:27:17: VRRP: Interface vlan200 Grp 1 Advertisement priority 120,

ipaddr 100.1.1.100

Note:



4. Check whether there is a ring in the networking and whether there are blocked ports.

3-27



Eliminate the loop fist and then check the STP configuration. Ensure the port accrosswhich the VRRP advertisements are delivered is not blocked.For the detailed solutions,determine the particular symptom and then refer to the corresponding cases below:"3.3 Troubleshooting Case: STP Loop Storm", "3.4 Troubleshooting Case: State ofSTP Topology Structure Keeps Fluctuating", and "3.6 Troubleshooting Case: STPDesignated Port is in a Continuous State of Discard". If the problem still cannot besolved, seek technical support.


3.9 Troubleshooting Case: VRRP Backup Group StateFluctuates Repeatedly

The backup device works in an unstable state. It switches frequently from the backup stateto the master state and then to the backup state again. The error messages are as follows.

11:47:44 11/14/2012 UTC alarm 22016 occurred %VRRP% Group 1 of vlan200 changing to

Backup sent by MCP


Master sent by MCP


Backup sent by MCP

VRRP (Virtual Router Redundancy Protocol) Figure 3-15 shows the troubleshootingprocedure for the case that VRRP backup group state fulctuates repeatly.

3-28



Figure 3-15 Troubleshooting Procedure Diagram for the Case that VRRP Backup Group StateFluctuates Repeatedly

Steps1. Check whether the link over which the VRRP advertisements are delivered fluctuates.

Repeatly use the show interface command to check whether thephysical interface for the VRRP advertisement delivery fluctuates. If the VRRP Trackis configured, the link state of the track interface should also be noticed becauseunstable track interface can cause the VRRP state to fluctuate. The VRRP devicepriority changes upon the link state change of the track interface.

ZXR10#show interface gei_0/1/1/1

gei_0/1/1/1 is up, line protocol is up

physical down time: 21:39:24 Sun Dec 23 2001

protocol down time: 21:39:24 Sun Dec 23 2001

3-29



Description is none


Duplex full

Mdi type:auto

MTU 1500 bytes BW 1000000 Kbits

Last clearing of "show interface" counters never

20 seconds input rate : 159 Bps, 0 pps

20 seconds output rate: 86 Bps, 0 pps

2. Check whether the STP fluctuates.

If STP is enabled, use the show logging alarm command to check whether there aremessages about fluctuating STP state on ports in the historical alarm logs.Frequentstate switch of STP can result in the frequent state switch of VRRP. The STP stateof the link over which VRRP packets are delivered must be stable. If the STP statefluctuates, refer to "3.4 Troubleshooting Case: State of STP Topology Structure KeepsFluctuating" to handle the problem

.

3. Check whether the VRRP advertisements are sent and received successfully.

When there is a traffic jam or a ring in the network, the backup device may have towait till timeout before it receives the advertisements from the master device, and thiscan result in the frequent stage change between master and backup.

Enable the VRRP debugging function on the backup device. Ensure that the devicecan receive the VRRP packet on time.

ZXR10#debug vrrp packet vrid 1

VRRP group 1 packet debugging is on

00:14:18: VRRP: Interface vlan12 Grp 1 Advertisement priority 100, ipaddr

100.1.1.100


100.1.1.100


100.1.1.100


100.1.1.100

Note:


For equipment in the existing networking, never execute the debug all command toenable all debugging switches all.

3-30



4. Check whether the CPU occupancy is normal.

When the system CPU is overloaded, the device may fail to handle the VRRP packetsproperly or in time.

Use the show processor command to check whether the CPU usage of the systemis too high. If it exceeds the threshold of 75%, refer to "3.22 Troubleshooting Case:System CPU Overload Alarm" to handle the problem.

ZXR10#show processor

PhyMem: Physical memory (megabyte)

Panel CPU(5s) CPU(1m) CPU(5m) PhyMem Buffer Memory

MP(M) 1 100% 100% 92% 512 0% 75.279%


3.10 Troubleshooting Case: ARP Learning Partly FailsFigure 3-16 shows the topology structure. The result of the Show arp command shows thatSwitch A has learned PC1's Address Resolution Protocol (ARP), but fails to learn PC2'sARP.

Figure 3-16 Topology Structure for the Fault that ARP Learning Partly Fails

Figure 3-17 shows the troubleshooting procedure for the case that ARP learning partlyfails.

3-31



Figure 3-17 Troubleshooting Procedure Diagram for the Case that ARP Learning Partly Fails

Steps1. Check whether the port can learn MAC address successfully.

Use the show mac table command and the show mac table interface command to check whether the port has learned the MAC address of thedestination node.

ZXR10(config)#show mac table 0000.0000.0002

3-32



Total MAC address : 0

Flags: Src--Source filter, Dst--Destination filter

From:0,driver;1,config;2,VPN;3,802.1X;4,micro;5,DHCP;

6,PBT;7,EVB;8,OTV;9,TRILL,

Time--Day:Hour:Min:Sec

MAC VLAN Outgoing Information Attribute From Time

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

ZXR10(config)#show mac table interface gei-0/1/1/2







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

0000.0000.0001 11 gei-0/1/1/2 Dynamic 0 00:19:47:49

If the port fails to learn the MAC address of the destination node, proceed with thefollowing steps:

a. Check whether the MAC address learning function is disabled on the port.

Use the show mac learning interface command to check whetherthe MAC address learning function is wrongly disabled on the designated port.

ZXR10(config)#show mac learning interface gei-0/1/1/2

The MAC learn is disabled.

ZXR10(config)#mac

ZXR10 (config-mac)#learning enable interface gei-0/1/1/2

b. Check whether the number of MAC entries that the port has learned exceeds thethreshold.

If there is a configured limit on the number of MAC entries a port can learn, usethe show mac limit-maximum interface command and the showmac table interface command to check whether the number ofMAC entries learned exceeds the limit. If yes, use the limit-maximum interface command to reconfigure the limit.

ZXR10(config)#show mac table interface gei-0/1/1/2




3-33






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

0022.9354.f8f9 11 gei-0/1/1/2 Dynamic 0 00:19:55:21

ZXR10(config)#show mac limit-maximum interface gei-0/1/1/2

MAC port gei-0/1/1/2 limit-maximum is 557056.

ZXR10(config)#mac

ZXR10(config-mac)#limit-maximum 2 interface gei-0/1/1/2

18:07:38 05/11/2007 UTC alarm 22792 occurred %MAC%

MAC address number drop to threshold sent by MCP

c. Check whether the MAC address of the destination node is statically bound toother ports by mistake.

Use the show mac table vlan command to check whether theMAC address of the destination node is statically bound to other ports in the sameVLAN. If yes, use the delete vlan command to delete theerroneous configuration.

ZXR10(config)#show mac table 0000.0000.0002 vlan 11







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

0000.0000.0002 11 gei-0/1/1/2 Dynamic 0 00:00:07:49

ZXR10(config)#mac

ZXR10(config-mac)#delete 0000.0000.0002 vlan 11

2. Check whether ARP packets are sent and received successfully.

Use the debug arp trace send source command and the debug arp trace receive source command to enable the ARP debugging function, and then ping the destination node. If there is no printedmessages about the sending and receivingof the corresponding ARP packets, verify whether traffic can be forwarded over thelink successfully and whether the source and destination nodes have successfullysent the ARP packets through packet capture. If there are lost packets during trafficforwarding over the link, refer to "3.2 Troubleshooting Case: Some Packets are Lostduring Traffic Forwarding over the Link" to handle the problem. If the source nodecannot successfully send the ARP packets, verify whether the IP stack works normally.

ZXR10#debug arp trace send source 1.1.1.254

3-34



ARP debugging trace is on

ZXR10#debug arp trace receive source 1.1.1.1

ARP debugging trace is on

ZXR10#ping 1.1.1.2

Sending 5,100-byte ICMP echoes to 1.1.1.2,timeout is 2 seconds.

18:38:44 Arp request packet in master rp of src ip 1.1.1.254, dst ip 1.1.1.2

sends in arp send request program

18:38:44 Arp request packet in master rp of src ip 1.1.1.254, dst ip 1.1.1.2,

src mac 00d0.d0c0.1121, dst mac 0000.0000.0000 sends

successfully

18:38:44 Arp received reply packet in master rp of src ip 1.1.1.2,

dst ip 1.1.1.254, src mac 0000.0000.0002, dst mac 00d0.d0c0.1121

deals successfully!!!!!

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

ZXR10#

3. Check whether the number of ARP entries that the port has learned exceeds thethreshold.

Ping the destination node to check whether the error that the number of ARP entriesexceeds the threshold is printed as follows. If yes, it indicates that the number of thelearned ARP entries exceeds the configured threshold. Use the arp protect interfacelimit-num command to modify the threshold.

ZXR10#ping 1.1.1.2

Sending 5,100-byte ICMP echoes to 1.1.1.2,timeout is 2 seconds.

19:02:12 05/11/2007 UTC alarm 19713 occurred %ARP% The arp packet of IP address

1.1.1.2 is discarded,

because it exceeds arp protect interface limit-num 2 sent by MCP.



because it exceeds arp protect interface limit-num 2 sent by MCP.



because it exceeds arp protect interface limit-num 2 sent by MCP

Success rate is 0 percent(0/2).

ZXR10(config)#interface vlan11

ZXR10(config-if-vlan11)#arp protect interface limit-num 2


3.11 Troubleshooting Case: IGMP Snooping User Failsto be Online

Figure 3-18 shows that the IGMPSnooping protocol runs between the switch and the usersin this networking scenario. A user sends a new membership report to the switch to makea request to join Group G. However, execute the show ip igmp snooping command on the

3-35



switch only to find that there are no messages showing that the user has joined Group G.The user fails to be online.

Figure 3-18 The Fault that IGMP Snooping User Fails to be Online

Figure 3-19 shows the troubleshooting procedure for the case that IGMP Snooping userfails to be online.

3-36



Figure 3-19 Troubleshooting Procedure Diagram for the Case that IGMP SnoopingUser Fails to be Online

Steps1. Check whether the interface is in up state.

The interface that the host is connected to must be ensured to be in link-up state first.Otherwise, the interface cannot send or receive user's service packets successfully.Observe the state of the link indicators of the two interconnected interfaces and usethe show interface command to check whether the protocol is in up

3-37



state. Refer to "3.1 Troubleshooting Case: Ports Fail to Work in Link-up State" for thedetailed troubleshooting procedure.

ZXR10(config)#show interface gei-0/1/1/11

gei-0/1/1/11 is up, line protocol is up, IPv4 protocol is up, IPv6 protocol is down

Hardware is Gigabit Ethernet, address is 00d0.d115.e000

BW 1000000 Kbps

MTU 1600 bytes


Duplex full

Negotiation auto

Mdi type:auto


2. Check whether the VLAN properties of the interface are correct.

If the VLAN properties of the interface that the user is directly connected to are notcorrect, the switch cannot process the new membership report in the right VLAN. Inthis way, the user fails to be online.

Use the show vlan id command to check the current configuration of theinterface and the vlan member. Make sure that the interface that the user is directlyconnected to is right in the VLAN. ( By default, an interface is in VLAN 1 ).

ZXR10(config)#show vlan id 1

VLAN Name PvidPorts UntagPorts TagPorts

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

1 vlan0001 gei-0/1/1/2-3 gei-0/1/1/11-12

gei-0/1/1/8-10

gei-0/1/1/17-48

xlgei-0/1/3/1-2

3. Check whether the IGMP Snooping function is enabled globally and enabled in theVLAN.

Excute the show running-config igmp-snoop command on the device to check whetherthe IGMP Snooping function is enabled globally and enabled in the VLAN.

The user VLAN is assumed to be VLAN 100.

ZXR10(config)#show running-config igmp-snoop

!

igmpsnoop

igmp snooping disable

vlan 100

igmp snooping enable

$

$

Enable the IGMP Snooping functions are in global or VLAN according to the actualdisplay case.

3-38



By default, the IGMP Snooping function is enabled globally and disabled in VLANs onthe ZXR10 5900E.

4. Check whether the interface has received the correct new membership report.

Use the terminal monitor and debug igmpsnoop packet command on the deviceto enable the packet receiving debugging of the IGMP Snooping function on theinterface. Check the debugging messages about the IGMP membership reportpackets received by the interface that the host is directly connected to.If there is nodebugging messages, it indicates that the port does not receive the membershipreport packets. Check the multicast client software on the host. Make sure that it runsproperly and has sent the packets successfully.

Note:

After locating the problem, do execute the no debug all command to disable debuggingmode and no terminal monitor command to disable display. Otherwise, long-timedebugging can occupy excessive system resources.


5. Check whether the ACL group filter of the IGMP Snooping is configured on the device.

Use the show ip igmp snooping vlan command to check whether theACL group filter of the IGMP Snooping is configured in the user's VLAN. Use the showacl command to check the detailed configuration of ACL. If Group G is not inthe ACL range, modify or delete the ACL configuration.

ZXR10(config-vlan1)#show ip igmp snooping vlan 1

IGMP snooping is globally enabled.

IGMP snooping is enabled in this VLAN.

IGMP snooping is working in the proxy mode.

IGMP snooping querier is disabled in this VLAN.

IGMP snooping fast-leave is disabled in this VLAN.

IGMP snooping dynamic-learning-closedown is disabled in this VLAN.

IGMP snooping ACL is 1 in this VLAN.

IGMP snooping max group number is 4096 in this VLAN.

IGMP snooping host time out is 260s in this VLAN.

IGMP snooping mrouter time out is 260s in this VLAN.

IGMP snooping last member query interval is 1s in this VLAN.

IGMP snooping proxy IP is not configured in this VLAN.

IGMP snooping query IP is not configured in this VLAN.

IGMP snooping topology change sending general query is disabled in this VLAN.

IGMP snooping topology change sending special leave is disabled in this VLAN.

3-39



IGMP snooping topology change responsing special leave is disabled in this VLAN.

ZXR10 #show ipv4-access-lists name 1

ipv4-access-list 1

1/1 (showed/total)

1 permit igmp any 225.0.0.1 0.0.0.255

Note:

At the end of each ACL, there is an invisible rule to deny all packets. The rule is addedby the system automatically. If the group address of the multicast group doesn't matchany of the visible rules, it will match the invisible rule and then be discarded.

6. Check whether there is limit on the number of the group.

If other users have joined the group on the device, check whether there is limit on groupnumber and on user number.Use the show ip igmp snooping vlan command toview whether the existing group number and user number have reached the configuredthreshold.l If yes, increase the value in the user's VLAM or use the no ig snooping max-grou

p-num command to cancel the limit.l If no, use the show ip igmp snooping summary command to check the peer group

was added exceeds the 1024 total..

ZXR10(config)#show ip igmp snooping vlan 1

IGMP Snooping is globally enabled.

IGMP Snooping is enabled in this vlan.

IGMP Snooping is working in the proxy mode.

IGMP Snooping querier is disabled in this vlan.

IGMP Snooping fast-leave is disabled in this vlan.

IGMP Snooping acl is 1 in this vlan.

IGMP Snooping max group number is 20 in this vlan.

IGMP Snooping host time-out is 260s in this vlan.

IGMP Snooping mrouter time-out is 260s in this vlan.

IGMP Snooping last member query interval is 1s in this vlan.

IGMP Snooping proxy-ip is none in this vlan.

IGMP Snooping total-group-num is 1 in this vlan.

IGMP Snooping exist-host-group-num is 0 in this vlan.

IGMP Snooping cfg-drop-group-num is 0 in this vlan.

IGMP Snooping cfg-prejoin-group-num is 0 in this vlan.

IGMP Snooping cfg-max-host-group-num is 1 in this vlan.

S = Static; D = Dynamic.

3-40



Index VLAN Group ID Drop Prejoin MaxHostNum Ports

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

1 1 225.1.1.1 0 0 10 NUL


3.12 Troubleshooting Case: The Program Fails to PlaySmoothly When being Viewed by Users.

When users view the program they ordered via STB (Set Top Box), the program fails toplay smoothly. While it is playing, it may stop unexpectedly, pause for a moment and thencontinue again.

Figure 3-20 shows the troubleshooting procedure for unsmooth programs when beingviewed.

Figure 3-20 Troubleshooting Procedure Diagram for Unsmooth Programs When beingViewed

Steps1. Check whether the frame dropping of unknown multicast group is configured.

By default, the ZXR10 5900E broadcasts the unknown multicast group packets thatno users have ordered in VLANs in the Layer 2 network; Therefore, if all the multicastpacket streams from the upstream device have been pushed to the switch, users will

3-41



receive all the multicast group packets consisting of the ordered ones and the unknownones. In this way, the STB may be overloaded and then drop some frames. Theproblem can be solved by configuring frame dropping of unknown multicast group tostop the unknown multicast group packets from being broadcast in VLANs.

Use the show running-config igmp-snoop command to check whether"unknown-group drop" is configured in the VLAN. If no, configure unknown-groupdrop in the user's VLAN.

ZXR10(config)#show running-config igmp-snoop

!

igmpsnoop

vlan 1

igmp snooping enable

igmp snooping acl 1

igmp snooping drop 225.0.0.1

$

2. Check whether multicast-limit is configured on the uplink interface (the interface toreceive the multicast pakckets).

If multicast-limit is configured on the uplink interface of the switch, the packets that tryto go through the interface may be droped by the switch. In this case, the programmayplay unsmoothly when being viewed by users. Use the show running-config | be multicast command to check whether multicast-limit is configured on the uplink interface. Ifyes, execute themulticast-limit percent 100 command on the uplink interface to deleteit.

ZXR10(config)#show running-config | be multicast


unknowncast-limit percent 10

$


broadcast-limit percent 10


unknowncast-limit percent 10 end

ZXR10(config)#interface gei-0/1/1/2

Z

ZXR105900ESeriesnova-minsk.com/ZTE/59E/SJ-20150114102049-012-ZXR10... · ZXR105900ESeries...

Documents

Transcript of ZXR105900ESeriesnova-minsk.com/ZTE/59E/SJ-20150114102049-012-ZXR10... · ZXR105900ESeries...