ZXR10 5900E Series

ZXR10 5900E Series

Easy-Maintenance MPLS Routing Switch

Troubleshooting

Version: 3.00.11

ZTE CORPORATION

No. 55, Hi-tech Road South, ShenZhen, P.R.China

Postcode: 518057

Tel: +86-755-26771900

Fax: +86-755-26770801

URL: http://support.zte.com.cn

E-mail: [email protected]

LEGAL INFORMATION

Copyright © 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.

R1.0

Revision Date

2015-01-15

Revision Reason

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

Contents

About This Manual ......................................................................................... I

Chapter 1 Troubleshooting Overview....................................................... 1-1

1.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-1

2.1 Power Troubleshooting ....................................................................................... 2-1

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

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

Chapter 3 Software Troubleshooting........................................................ 3-1

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

3.2 Troubleshooting Case: Some Packets are Lost during Traffic Forwarding over the 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 Same

MSTP Domain................................................................................................ 3-15

3.6 Troubleshooting Case: STP Designated Port is in a Continuous State of

Discard .......................................................................................................... 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 Backup

Group ............................................................................................................ 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 being

Viewed 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 When being Connected to the DHCP Server Directly .................................................. 3-49

SJ-20150114102049-012|2015-01-15 (R1.0)

I

ZTE Proprietary and Confidential

3.16 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCP

Snooping ....................................................................................................... 3-53

3.17 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCP

Relay ............................................................................................................. 3-57

3.18 Troubleshooting Case: Users of a Switch Fail to Receive Traffic in PIM_SM

Environment................................................................................................... 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

SJ-20150114102049-012|2015-01-15 (R1.0)

II


About This Manual

Purpose

This manual is the ZXR10 5900E Series (V3.00.11) Easy-Maintenance MPLS Routing

Switch Troubleshooting, which is applicable to the ZXR10 5900E (V3.00.11) series switches.

This manual describes common problems associated with the ZXR10 5900E Series switch, the relevant solutions and preventive measures.

Intended Audience

This manual is intended for: l

Network maintenance engineers l Testing engineers l

On-duty personnel

What Is in This Manual

This manual contains the following chapters:

Chapter 1, Troubleshooting

Overview

Introduces the fault classification and relevant troubleshooting methods.

Chapter 2, Hardware

Troubleshooting

Chapter 3, Software

Troubleshooting

Introduces the hardware faults associated with the ZXR10 5900E Series switch, the relevant solutions and preventive measures.

Introduces the software faults associated with the ZXR10 5900E Series switch, the relevant solutions and preventive measures.

Conventions

This manual uses the following typographical conventions:

Italics

Bold

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

Menus, menu options, function names, input fields, option button names, check boxes, drop-down lists, dialog box names, window names, parameters, and commands.

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

Constant width

[ ]

{ }

|

{x|y|z}

Optional parameters.

Mandatory parameters.

Separates individual parameters in a series of parameters.

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.

SJ-20150114102049-012|2015-01-15 (R1.0)

II


Chapter 1

Troubleshooting Overview

Network troubleshooting is performed based on knowledge about network principles, network configurations and network operation. It is an activity to repair a faulty network by

1.

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 network l Finding out imperfections in network planning and configurations to improve and optimize network performance l

Observing the running status of the network to timely predict network communication quality l

Summarizing troubleshooting experience in time to avoid similar faults

Table of Contents

Fault Classification .....................................................................................................1-1

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

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

1.1 Fault Classification

Switch faults are generally classified into hardware faults and software faults.

1.1.1 Hardware Fault

The hardware faults are service interruptions or poor performance caused by the hardware of 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 fans stop running due to an unstable external power supply, aging power circuitry or lighting.The power supply faults may cause damage to other components of the switch.

l

Fan fault

The fan status directly affects the heat dissipation and operation of the entire switch. If the 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 the hardware may be damaged.

l Port fault

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

1.1.2 Software Fault

The software faults are the faults in the system or the configurations, and can be classified into the following categories: l

System error l

Improper configuration l

External factors

1.2 Troubleshooting Methods

There are various switch faults, and each fault has its own symptoms. Use the appropriate methods for different symtoms when analyzing faults, then locate the faulty point and solve the problem in time.

l

Exclusion

The exclusion method is to list all possible causes based on the observed fault symptoms, and then analyze and remove them one by one.

Abide by the simple-to-difficult principle to improve efficiency. This method is applicable to all types of faults. However, it requires that maintenance engineers should have strong logical 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 and the existing switches that are of the same type and work properly. This method is simple and effective, especially for the faults in system configurations. The difference in configurations can be easily found through simple observation.

l

Substitution

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

SJ-20150114102049-012|2015-01-15 (R1.0)

1-2


Chapter 1 Troubleshooting Overview

1.3 Emergency Help

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

l Hotline

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

l Remote technical support

ZTE technicians can remotely log in to the site where the faults occur according to the information provided by the hotline. ZTE technicians instruct customers over the phone to solve general problems. For complicated problems, ZTE sends maintenance experts to the site.

l On-site technical support

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

SJ-20150114102049-012|2015-01-15 (R1.0)

1-3


ZXR10 5900E Series Troubleshooting

This page intentionally left blank.

SJ-20150114102049-012|2015-01-15 (R1.0)

1-4


Chapter 2

Hardware Troubleshooting

Figure 2-1

shows the general procedure for hardware fault troubleshooting.

Figure 2-1 General Procedure for Hardware Fault Troubleshooting


Power Troubleshooting...............................................................................................2-1

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

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

2.1 Power Troubleshooting

Fault Description

Based on the type of the device and the quantity of power supplies, the possible symptoms of a power supply fault may include the following: l Power-off of the equipment.

2-1


ZXR10 5900E Series Troubleshooting 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 Measures

Check the device state and indicator state. Use the

show power

command to check the power 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, the

Uninterruptable Power Supply (UPS) devices can be used to ensure the normal power supply for the switches. When choosing the UPS devices, note that some UPS devices provide a voltage-stabilizing function, while some do not.

2.2 Fans Troubleshooting


Based on the type of the device and the quantity of power supplies, the possible symptoms of the fan fault include the following: l The device overheats and fans fail to work properly l

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-high voltage 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.


Steps for troubleshooting fans are as follows:

1.

Check the power supply state. If the voltage is abnormal, restore the power supply to normal 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 power

supply modules work normally.

SJ-20150114102049-012|2015-01-15 (R1.0)

2-2


Chapter 2 Hardware Troubleshooting

2.

Clean and maintain fan modules regularly to avoid dust accumulation.

The accumulation 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 Troubleshooting


A port fault may involve one or multiple faulty ports. The faulty ports can be found by changing the port that the PC is connected to if the PC has been verified to be normal.


For such faults, power off the switch and then clean the faulty port with alcohol cotton.If

the service still cannot be recovered, the port is verified to be damaged. Change the port or 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 the hardware of fans.

l

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

l

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

SJ-20150114102049-012|2015-01-15 (R1.0)

2-3




SJ-20150114102049-012|2015-01-15 (R1.0)

2-4


Chapter 3

Software Troubleshooting


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

Troubleshooting Case: Some Packets are Lost during Traffic Forwarding over the

Link ............................................................................................................................3-5

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

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

Troubleshooting Case: Multiple Devices Fail to Work Well Together in the Same

MSTP Domain..........................................................................................................3-15

Troubleshooting Case: STP Designated Port is in a Continuous State of Discard.....3-19

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

Troubleshooting Case: Dual Devices are in Master State in the VRRP Backup

Group.......................................................................................................................3-24

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

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

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

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

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

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

Troubleshooting Case: DHCP Client Fails to Obtain an IP Address When being

Connected to the DHCP Server Directly ...................................................................3-49

Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCP

Snooping..................................................................................................................3-53

Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via DHCP

Relay........................................................................................................................3-57

Troubleshooting Case: Users of a Switch Fail to Receive Traffic in PIM_SM

Environment .............................................................................................................3-60

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

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

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

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

3.1 Troubleshooting Case: Ports Fail to Work in

Link-up State

Figure 3-1

shows that PORT 1 and PORT 2 fail to work in link-up state after being connected 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-up state.

Figure 3-2 Troubleshooting Procedure Diagram for the Case that Ports Fail to Work in

Link-up State

Steps

1.

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 the link-up failure. Such problems can be eliminated by substituting a new and high-quality cable for the old one. If PORT 1 and PORT 2 are Ethernet optical ports, the TX and

RX connections of the optical fiber cable must be verified to be correct, that is, the TX of the local end must connect the RX of the peer end and the RX of the local end must connect the TX of the peer end.

2.

Check whether the properties and configurations of the local port are consistent with those of the peer port.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-2


Chapter 3 Software Troubleshooting

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

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

Port Configurations of Ethernet Electrical Ports

PORT 1 PORT 2

GE negotiation auto

GE negotiation auto

GE negotiation auto

FE negotiation auto

FE negotiation auto

GE no negotiation auto speed 100 duplex full(default)

FE negotiation auto

FE no negotiation auto speed 100(default) duplex full(default)

Negotiation Result

PORT 1 PORT 2

1000M/Full

100M/Full

1000M/Full

100M/Full

100M/Full

100M/Full

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

PORT 1

GE negotiation auto

GE no negotiation auto duplex full(default)

PORT 2

GE negotiation auto

GE no negotiation auto duplex full(default)

10GE negotiation auto

10GE no negotiation auto duplex full(default)


PORT 1

1000M/Full

1000M/Full

10GE negotiation auto 10000M/Full

10GE no negotiation auto duplex full(default)

10000M/Full

PORT 2

1000M/Full

1000M/Full

10000M/Full

10000M/Full a.

Use the

show interface

<interface-name>

command to check the current properties of a port. "

electric

" indicates that it is an ethernet electrical port. "

BW 1000000

Kbits

" 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 current configuration of a port. Auto-negotiation is enabled by default for the ports of the

ZXR10 5900E. (Contents with the "#" mark are the default configurations.)

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

!<ETHER_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

!<ETHER_PORT> interface gei-0/1/1/1 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 of the optical module on PORT 1 and PORT 2. Make sure that the information of the optical module on PORT 1 is the same as that on PORT 2. The information includes "

Type

" and "

Length

" (The DOM function is disabled by default for the ports of the ZXR10 5900E. The function can be enabled by

optical-inform monitor enable

.)

ZXR10(config)#show optical-inform interface xgei-0/1/2/1

Portname

WaveLen

Online EtherProperty Vendor

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

VendorPN VendorSN Type Length

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

3-4



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

FTLX1471D3BCL

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

AP101BT single

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 problem still cannot be solved after all the above factors have been verified to be alright. The state of an optical module can be verified by the single-port loopback method. The state of an ethernet port can be verified by the substitution method; An available idle port can be substituted for the port to be checked.

– End of Steps –

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

Figure 3-3

shows that there are lost packets in the traffic from PORT 1 to PORT 2 in this topology 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 forwarding over the link.

Figure 3-4 Troubleshooting Procedure Diagram for Lost Packets during Flow

Forwarding over the Link

SJ-20150114102049-012|2015-01-15 (R1.0)

3-5



Steps

1.

Check whether the port property is half-duplex.

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

Port Configuration Pair

PORT 1

negotiation auto negotiation auto negotiation auto

PORT 2

negotiation auto no negotiation auto duplex full no negotiation auto duplex half no negotiation auto duplex full no negotiation auto duplex full no negotiation auto duplex full no negotiation auto duplex half no negotiation auto duplex half no negotiation auto duplex full no negotiation auto duplex half no negotiation auto duplex full


PORT 1 PORT 2

full half full full half full full half half half full half full half

The first pair is recommended. If the negotiation fails and the ports fail to work in

Link-up state, the fourth pair can be used. (Note that an electrical port with the rate of

1000Mbps does not suport this pair.) No other pairs are recommended.

a.

Use the

show interface

<interface-name>

command to check the current properties of a port. "

Duplex full

" indicates the port is working in full-duplex state. (

half

for half-deplex state), "

BW 1000000 Kbits

" indicates the port is working 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


BW 1000000 Kbps

MTU 1600 bytes


Duplex full

Negotiation auto

Mdi type:auto



3-6



120s output rate: 0Bps 0Pps b.

Use the

show running-config eth-port

[

all

] command to check the current configuration of a port. Auto-negotiation is enabled by default for the ZXR10

5900E ports. (Contents with the "#" mark are the default configurations.)

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

!<ETHER_PORT> interface gei-0/1/1/1 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 there are errors that have been recorded by the counters.

After ensuring that both of the two interconnect ports work in full-deplex state, use the

show interface

command to check the reports on the received and transmitted packets 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 link commnunication of the port is of poor quality. The corresponding cable or port should be changed.

For counter

Undersize

" and "

Oversize

", the ZXR10 5900E can forward packets with the length ranging from 64 to 1560 bytes by default. The packet whose length is smaller than 64 bytes will be discarded and recorded by

Undersize

". The packet whose 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 does exceed 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



0Pps 120s output rate: 0Bps

Peak rate: input 0Bps output 0Bps

Intf utilization: input 0% peak time peak time output 0%

N/A

N/A

HardWareCounters:

In_Bytes 0

In_Unicasts

In_Multicasts

In_CRC_ERROR

In_Fragments

In_MacRxError

0

0

0

0

0

In_Packets

In_Broadcasts

In_Undersize

In_DropEvents

In_Jabbers

In_64B

0

0

0

0

0

0

In_65_127B

In_256_511B

In_1024_1518B

E_Bytes

E_Unicasts

E_Multicasts

E_LateCollision

E_65_127B

E_256_511B

E_1024_1518B

0

0

0

0

0

0

0

0

0

0

In_128_255B

In_512_1023B

In_Oversize

E_Packets

E_Broadcasts

E_SingCollision

E_64B

E_128_255B

E_512_1023B

E_Oversize

0

0

0

0

0

0

0

0

0

0


3.3 Troubleshooting Case: STP Loop Storm

Figure 3-5

shows that Switch B does not abide by the STP protocol to block PORT 3 in this

STP

(Spanning Tree Protocol) ring networking scenario, so loop storm occurs among the six ports in the ring.

SJ-20150114102049-012|2015-01-15 (R1.0)

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

Steps

1.

Check whether STP is enabled globally.

3-9



STP is disabled globally by default.

Use the

show spantree instance 0

command to check whether global STP is enabled. If no, configure

spantree enable

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

<interface-name>

command to check whether STP is enabled on the node. If no, that is, The port is STP disabled! , configure

spantree enable

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

IEEE

format. 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/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 the interconnected ports in the ring.

Use the

debug spantree

{

bpdu-rx

|

bpdu-tx

}

interface

<

interface-name

> command to check the debugging messages about how a specified port receives and transmits

BPDU packets.

Note:

After locating the problem, do execute the

no debug all

command to disable debugging mode. Otherwise, long-time debugging can occupy excessive system resources.

For equipment in the existing networking, never execute the

debug all

command to enable all debugging switches.

If the BPDU-TX of the peer end has sent printed log, but the BPDU-RX of the local end fails to receive the printed log within a specified period, it indicates that there may be lost packets when packets are being forwarded over the link. Refer to "

3.2

Troubleshooting Case: Some Packets 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 of

STP of the port is still incorrect, collect the printed logs of the

show spantree mst-config

command and the


<

interface-name

> command and the

debu g spantree

{

bpdu-rx

|

bpdu-tx

}

interface

<

interface-name

> command, and then seek technical 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


SJ-20150114102049-012|2015-01-15 (R1.0)

3-11



3.4 Troubleshooting Case: State of STP Topology

Structure Keeps Fluctuating

There are continual error log messages about state fluctuation in the

STP

topology structure as shown below.

UTC alarm 24326 occurred %STP% port <interface-name> instance <instance-id> topology detected. sent by MCP

UTC alarm 24326 occurred %STP% mst: role recompute instance <instance-id> sent by MCP

Figure 3-7

shows the troubleshooting procedure for continual state fluctuation in STP topology structure.

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

Structure

SJ-20150114102049-012|2015-01-15 (R1.0)

3-12



Steps

1.

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 as follows, 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

11:05:28 10/19/2012 UTC alarm 24326 occurred %STP% port gei-0/1/1/2 instance 0 state changed discard->learn. sent by MCP

11:05:43 10/19/2012 UTC alarm 24326 occurred %STP% port gei-0/1/1/2 instance 0 state 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. Use the

show interface

<

interface-name

> command to check the time point when the port last 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


120s input rate : 0Bps

120s output rate: 46Bps

0Pps

0Pps

Peak rate: input output

138Bps

98Bps

Intf utilization: input 0%

HardWareCounters: peak time peak time output 0%

2010-01-01 04:23:30

2010-01-01 05:01:40

In_Bytes

In_Unicasts

In_Multicasts

In_CRC_ERROR

In_Fragments

In_MacRxError

In_65_127B

In_256_511B

In_1024_1518B

E_Bytes

E_Unicasts

427364007185

0

1669399056

0

0

0

49

1668902663

0

427250868630

0

In_Packets

In_Broadcasts

In_Undersize

In_DropEvents

In_Jabbers

In_64B

In_128_255B

In_512_1023B

In_Oversize

E_Packets

E_Broadcasts

1669399056

0

0

156

0

13

496331

0

0

1668963964

0

3-13



E_Multicasts

E_LateCollision

E_65_127B

E_256_511B

E_1024_1518B

1668963964

0

2

1668910658

0

E_SingCollision

E_64B

E_128_255B

E_512_1023B

E_Oversize

0

0

0

3587

49717

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. Make sure 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 state of 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 are

2 seconds and 20 seconds, respectively. Use the

show spanning-tree instance 0

command to check the value of Hello-time and Max-Age that are configured for the 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

BridgeID: Priority

Hello-Time

32768;

32768;

Address

Address

00d0.d059.6030

00d0.d059.6030

2 sec; Max-Age 20 sec

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 BPDU packets of all equipment nodes are verified to be the same, check whether the

BPDU packets over the link can be transmitted and received successfully.

Use the

debug spantree

{

bpdu-rx

|

bpdu-tx

}

interface

<

interface-name

> command to check the debugging messages about how a specified port receives and transmittes the BPDU packets.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-14



Note:


no debug all



debug all


If the BPDU-TX of the peer end has sent printed log, but the BPDU-RX of the local end fails to receive the printed log within a specified period, it indicates that there may be lost packets when packets are being forwarded over the link. Refer to "

3.2

Troubleshooting Case: Some Packets 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 of STP of the port is still incorrect, collect the printed logs of the


command, the


<

interface-name

> command and the

debug spantree

{

bpdu-rx

|

bpdu-tx

}

interface

<

interface-name

> command, and then 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 to

Work 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 MSTP after

MSTP

is deployed in the ring network. (The result of the

show spantree instance

<

1-64

> command shows that the root port works in Master state in multiple instances.)

SJ-20150114102049-012|2015-01-15 (R1.0)

3-15



Figure 3-8 Troubleshooting Case: Multiple Devices Fail to Work Well Together in the

Same MSTP Domain

Figure 3-9

shows the troubleshooting procedure for the case that multiple devices fail to work well together in the Same MSTP domain.

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

Steps

1.

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

SJ-20150114102049-012|2015-01-15 (R1.0)

3-16



Use the


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

CISCO

HUAWEI

HUAWEI

Name

Revision

Instance

--------

0

Hmd5-key

Hmd5-digest

Hmd5-key

Hmd5-digest

: 0x13ac06a62e47fd51f95d2ba243cd0346

: 0x00000000000000000000000000000000

: 0x13ac06a62e47fd51f95d2ba243cd0346

: 0x00000000000000000000000000000000

: [00d0d0596030]

: 0

Vlans mapped

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

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 three conditions: 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. Use the

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]

CISCO Hmd5-key

CISCO Hmd5-digest

HUAWEI

HUAWEI

Name

Revision

Hmd5-key

Hmd5-digest

: [zte]

: 0

: 0x13ac06a62e47fd51f95d2ba243cd0346

: 0x00000000000000000000000000000000

: 0x13ac06a62e47fd51f95d2ba243cd0346

: 0x00000000000000000000000000000000

Instance

--------

0

Vlans mapped

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

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

command in MSTP configuration mode to modify it.


ZXR10(config-stp)#mst revision ?

<0-65535> 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 instance and VLAN is that all VLANs belong to instance 0. Use the

mst vlans

<

vlan-list

>

instance

<

instance-id

> command to modify it.

ZXR10(config-stp)#show spantree mst spanning-tree mode: [MSTP]

CISCO Hmd5-key : 0x13ac06a62e47fd51f95d2ba243cd0346

CISCO

HUAWEI

HUAWEI

Hmd5-digest

Hmd5-key

Hmd5-digest

: 0x00000000000000000000000000000000

: 0x13ac06a62e47fd51f95d2ba243cd0346

: 0x00000000000000000000000000000000

Name

Revision

Instance

--------

: [00d0d0596030]

: 0

Vlans mapped

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

0 1-4094


ZXR10(config-stp)#mst vlans ?

<1-4094> VLAN id or VLAN rang

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

<1-64> 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


SJ-20150114102049-012|2015-01-15 (R1.0)

3-18



3.6 Troubleshooting Case: STP Designated Port is in a

Continuous State of Discard

The port whose

STP

role is Designated is in a continuous state of Discard * (the normal state of a blocked port is "Discatd" without "*".), and fails to complete the state change from discard to learn, and eventually to forward.


MST01

Spantree enabled protocol MSTP

RegRootID: Priority 1; Address 0022.9354.f8f8

Hello-Time 4 sec; Max-Age 20 sec

Forward-Delay 15 sec;

BridgeID: Priority

Hello-Time

32769; Address 00d0.d0c0.0000

4 sec; Max-Age 20 sec

Forward-Delay 15 sec; Max-Hops 20

Message-Age 0 sec; RemainHops 19

Interface

Name

Prio.Nbr

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 is in a continuous state of discard *.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-19



Figure 3-10 Troubleshooting Procedure Diagram for the Case that STP Designated Port is in a

Continuous State of Discard *

Steps

1.

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 switch whose bridge ID is lower than that of the current root bridge accesses the network after the network completes the spanning tree calculation, the new bridge will take over the role 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 via which the device accesses the network. If the bridge receives Bridge Protocol Data

Units (BPDUs) with lower bridge ID on a root guard-enabled port, root guard moves this port to a root-inconsistent STP state. Once the bridge stops receiving BPDUs with lower bridge ID, the port will go from the listening state to the learning state, and eventually 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 switch to the designated port and be in a blocking state of "Discard *", and the entire STP topology 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


Chapter 3 Software Troubleshooting sent by MCP" in the error log, it indicates that root guard is enabled on the port and the port has received attack from

BPDU

with a lower bridge ID. Check whether root guard is wrongly enabled on the port that needs to participate in the STP calculation.If

the configuration is verified to be wrong, disable the root guard on the port, otherwise locate 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 the blocked port fails to receive the BPDU packets due to unidirectional communication.

when a blocked port fails to receive the BPDU packets because of unidirectional communication, STP moves the blocking port to a forwarding state, which leads to a loop. The problem can be solved by configuring loop guard on the port. For the blocked port on which loop guard is enabled, it enters the LOOP_INCONSISTENT state if it does not receive BPDU packets any longer. No traffic is forwarded across this port. The port automatically returns to the BLOCK state once it receives BPDUs again.

Designated ports do receive the BPDUs from the peer when the topology structure is stable, so loop guard cannot be enabled on designated ports. Otherwise, the designated 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 instance

1 sent by MCP" in the error log, it indicates that loop guard is enabled on the port and the port doesn't receive the BPDUs from the peer. Check whether loop guard is wrongly enabled on the port that needs to participate in the STP calculation.If the configuration 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 to be in Up State

Figure 3-11

shows that the

ZESR

ring network fails to be in up state after being configured.

SJ-20150114102049-012|2015-01-15 (R1.0)

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 fails to be in up state.

Figure 3-12 Troubleshooting Procedure Diagram for the Case that ZESR Ring Network

Fails to be in Up State

SJ-20150114102049-012|2015-01-15 (R1.0)

3-22



Steps

1.

Check whether ZESR is configured on the right port.

The ZESR misconfigurations on ports in the ring network can cause the ring network to fail to be in up state.Use the

show zesr brief

command to check the ZESR configuration on 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 major master gei_0/1/1/1(P) gei_0/1/1/2(S) up switch-times

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

up

state.If no, refer to "

3.1 Troubleshooting Case: Ports Fail to Work in Link-up State

" to handle the problem.

ZXR10(config)#show interface brief

Interface portattribute mode BW(Mbits) Admin Phy gei_0/1/1/1 gei_0/1/1/2 electric electric

Duplex/full

Duplex/full

1000

1000 up up up up

Prot Description up up none 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 in the ring, no nodes in the ring can receive the flash-up packet from the master node. In this way, the ZESR ring network fails to be in up state.Use the

show zesr brief

command to check the role of each ZESR node configured on each device to see whether it is consistent with that in the networking planning and whether there is one master node.If

there 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 major master gei_0/1/1/1(P) gei_0/1/1/2(S) up switch-times

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-hello function 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 each port of the device in the ring.If the port is in "

special

" mode, it indicates that the link-hello function is enabled on the port. If the port is in "

normal

" mode, it indicates that the function is disabled. If the function is enabled on a port, verify that it is also enabled on the peer port. The configured hello-interval should be verified to be the same 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 Master

State in the VRRP Backup Group

Figure 3-13

shows that, in the normal situation, there is only one device that is in master state in the

VRRP

(Virtual Router Redundancy Protocol) backup group and all the other devices are in backup state. Multiple devices in master state can cause the hosts in the

LAN 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 backup group.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-24



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

Steps

1.

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 group configuration of one device is consistent with that of the other. The configurations that should be the same on both ends include VRID, authentication string, virtual

IP address. And the IP addresses of the interfaces should be in the same network segment. Use the

show vrrp interface

<

interface name

> command to check whether configurations of VRRP mode, preemption delay on both ends are the same.

ZXR10(config)#show running-config vrrp

<vrrp>!

vrrp interface vlan 200 vrrp 1 accept

3-25



!

end vrrp 1 ipv4 100.1.1.100

vrrp 1 priority 101 vrrp 1 version 2

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 group is 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 in link-up state. Otherwise, the port cannot send or receive VRRP advertisements.

Simply observe the link indicators of both ports and use the

show interface

<

inte rface-name

> 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 detailed troubleshooting procedure.

b.

Verify that the ports' VLAN properties are configured correctly. Use the

show run ning-config vrrp

command and the

show vlan id

<vlan-id>

command to check the current configuration of the port and the port members in the VLAN. Ensure that the 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 VRRP advertisements.

Use the

debug vrrp packet vrid

<

1-255

> command to check whether the backup group with lower priority receives illegal VRRP advertisements.

l

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

l

If yes, capture packets through the mirror port to check whether the received

VRRP advertisements are valid.

l If illegal, collect the printed log messagees of debug vrrp error / event/state group

X 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:


no debug all



debug all


4.

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

SJ-20150114102049-012|2015-01-15 (R1.0)

3-27



Eliminate the loop fist and then check the STP configuration. Ensure the port accross which 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 of

STP Topology Structure Keeps Fluctuating

", and "

3.6 Troubleshooting Case: STP

Designated Port is in a Continuous State of Discard ". If the problem still cannot be

solved, seek technical support.


3.9 Troubleshooting Case: VRRP Backup Group State

Fluctuates Repeatedly

The backup device works in an unstable state. It switches frequently from the backup state to 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 troubleshooting procedure for the case that VRRP backup group state fulctuates repeatly.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-28



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

Fluctuates Repeatedly

Steps

1.

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

Repeatly use the

show interface

<

interface-name

> command to check whether the physical interface for the VRRP advertisement delivery fluctuates. If the VRRP Track is configured, the link state of the track interface should also be noticed because unstable track interface can cause the VRRP state to fluctuate. The VRRP device priority 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


Last clearing of "show interface" counters never

20 seconds input rate : 159 Bps,

20 seconds output rate: 86 Bps,

0 pps

0 pps

2.

Check whether the STP fluctuates.

If STP is enabled, use the

show logging alarm

command to check whether there are messages about fluctuating STP state on ports in the historical alarm logs.Frequent

state switch of STP can result in the frequent state switch of VRRP. The STP state of the link over which VRRP packets are delivered must be stable. If the STP state fluctuates, refer to "

3.4 Troubleshooting Case: State of STP Topology Structure Keeps

Fluctuating

" 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 to wait till timeout before it receives the advertisements from the master device, and this can result in the frequent stage change between master and backup.

Enable the VRRP debugging function on the backup device. Ensure that the device can 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:


no debug all



debug all

command to enable all debugging switches all.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-30



4.

Check whether the

CPU

occupancy is normal.

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

Use the

show processor

command to check whether the CPU usage of the system

is 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)

MP(M)

Panel

1

CPU(5s) CPU(1m) CPU(5m)

100% 100% 92%

PhyMem

512

Buffer

0%

Memory

75.279%


3.10 Troubleshooting Case: ARP Learning Partly Fails

Figure 3-16

shows the topology structure. The result of the

Show arp

command shows that

Switch A has learned PC1's Address Resolution Protocol ( ARP ), but fails to learn PC2's

ARP.

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 partly fails.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-31



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

Steps

1.

Check whether the port can learn

MAC

address successfully.

Use the

show mac table

<

address

> command and the

show mac table interface

<

interf ace-name

> command to check whether the port has learned the MAC address of the destination 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 the following steps: a.

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

Use the

show mac learning interface

<

interface-name

> command to check whether the 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 the threshold.

If there is a configured limit on the number of MAC entries a port can learn, use the

show mac limit-maximum interface

<

interface-name

> command and the

show mac table interface

<

interface-name

> command to check whether the number of

MAC entries learned exceeds the limit. If yes, use the

limit-maximum

<

max-num

>

interface

<

interface-name

> command to reconfigure the limit.

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




3-33






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

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

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% <Port gei-0/1/1/2>

MAC address number drop to threshold sent by MCP c.

Check whether the MAC address of the destination node is statically bound to other ports by mistake.

Use the

show mac table

<

address

>

vlan

<

vlan id

> command to check whether the

MAC address of the destination node is statically bound to other ports in the same

VLAN. If yes, use the

delete

<

address

>

vlan

<

vlan id

> command to delete the erroneous 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

<ip address>

command and the

debug arp trace rec eive source

<ip address>

command to enable the ARP debugging function, and then

pin g

the destination node. If there is no printed messages about the sending and receiving of the corresponding ARP packets, verify whether traffic can be forwarded over the link successfully and whether the source and destination nodes have successfully sent the ARP packets through packet capture. If there are lost packets during traffic

forwarding over the link, refer to " 3.2 Troubleshooting Case: Some Packets are Lost during Traffic Forwarding over the Link

" to handle the problem. If the source node cannot 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 the threshold.

Ping

the destination node to check whether the error that the number of ARP entries exceeds the threshold is printed as follows. If yes, it indicates that the number of the learned ARP entries exceeds the configured threshold. Use the

arp protect interface limit-num

<max-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.


1.1.1.2 is discarded, because it exceeds arp protect interface limit-num 2 sent by MCP.


1.1.1.2 is discarded, 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 Fails to be Online

Figure 3-18

shows that the

IGMP

Snooping protocol runs between the switch and the users in this networking scenario. A user sends a new membership report to the switch to make a request to join Group G. However, execute the

show ip igmp snooping

command on the

3-35


ZXR10 5900E Series Troubleshooting 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 user fails to be online.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-36



Figure 3-19 Troubleshooting Procedure Diagram for the Case that IGMP Snooping

User Fails to be Online

Steps

1.

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 use the

show interface

<interface-name>

command to check whether the protocol is in

up

SJ-20150114102049-012|2015-01-15 (R1.0)

3-37



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


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 not correct, the switch cannot process the new membership report in the right VLAN. In this way, the user fails to be online.

Use the

show vlan id

<vlan-id>

command to check the current configuration of the interface and the vlan member. Make sure that the interface that the user is directly connected 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 gei-0/1/1/11-12 vlan0001 gei-0/1/1/2-3 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 the

VLAN.

Excute the

show running-config igmp-snoop

command on the device to check whether the 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

!<igmp-snoop> igmpsnoop igmp snooping disable

$

$ vlan 100 igmp snooping enable

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

3-38



By default, the IGMP Snooping function is enabled globally and disabled in VLANs on the 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 device to enable the packet receiving debugging of the IGMP Snooping function on the interface.

Check the debugging messages about the IGMP membership report packets received by the interface that the host is directly connected to.If there is no debugging messages, it indicates that the port does not receive the membership report packets. Check the multicast client software on the host. Make sure that it runs properly and has sent the packets successfully.

Note:


no debug all

command to disable debugging mode and

no terminal monitor

command to disable display. Otherwise, long-time debugging can occupy excessive system resources.


debug all


5.

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

Use the

show ip igmp snooping vlan

<vlan-number>

command to check whether the

ACL group filter of the IGMP Snooping is configured in the user's VLAN. Use the

show acl

<acl-id>

command to check the detailed configuration of

ACL . If Group G is not in

the 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 added by the system automatically. If the group address of the multicast group doesn't match any 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 group number and on user number.Use the

show ip igmp snooping vlan

<vlan-id>

command to view whether the existing group number and user number have reached the configured threshold.

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 Play

Smoothly When being Viewed by Users.

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

Figure 3-20

shows the troubleshooting procedure for unsmooth programs when being viewed.

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

Viewed

Steps

1.

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

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

3-41


ZXR10 5900E Series Troubleshooting receive all the multicast group packets consisting of the ordered ones and the unknown ones. In this way, the STB may be overloaded and then drop some frames. The problem can be solved by configuring frame dropping of unknown multicast group to stop 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-group drop

in the user's VLAN.

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

!<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 to receive the multicast pakckets).

If multicast-limit is configured on the uplink interface of the switch, the packets that try to go through the interface may be droped by the switch. In this case, the program may play unsmoothly when being viewed by users. Use the

show running-config

|

be multi cast

command to check whether multicast-limit is configured on the uplink interface. If yes, execute the

multicast-limit percent 100

command on the uplink interface to delete it.

ZXR10(config)#show running-config | be multicast multicast-limit percent 100 unknowncast-limit percent 10

$ interface gei-0/1/1/2 broadcast-limit percent 10 multicast-limit percent 100 unknowncast-limit percent 10 end

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

ZXR10(config-gei-0/1/1/2)#multicast-limit percent 100

3.

Check whether there are dropped packets over the link.

It there are dropped packets during traffic forwarding over the link between the device and the users, the program may play unsmoothly when being viewed by users. Refer to "

3.2 Troubleshooting Case: Some Packets are Lost during Traffic Forwarding over the Link " for the detailed troubleshooting procedure for lost packets.


SJ-20150114102049-012|2015-01-15 (R1.0)

3-42



3.13 Troubleshooting Case: IPTV Users Fail to Use the

VOD Function

Figure 3-21

shows that the

IPTV

function is enabled on the switch in this networking scenario to control user access. A user has ordered the channel CH-1 (the VOD service,

Video On Demand). However, execute the

show iptv client all

command on the switch only to find that there are no messages showing that the user is online. The user fails to receive the traffic of CH-1.

Figure 3-21 IPTV Users Fail to Use the VOD Function

Figure 3-22

shows the troubleshooting procedure for the case that IPTV users fail to use the VOD function.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-43



Figure 3-22 Troubleshooting Procedure Diagram for the Case that IPTV Users Fail to

Use the VOD Function

Steps

1.

Check whether IGMP Snooping is configured correctly.

For IPTV networking, first make sure that IGMP Snooping is configured on the user's

VLAN correctly. Refer to "

3.11 Troubleshooting Case: IGMP Snooping User Fails to be Online


2.

Check whether the channel or channel group is configured correctly and the privilege is granted.

a.

Check whether the privilege is granted correctly.

If users are not granted the privilege to order a channel, they cannot order and then view the channel or channel group successfully. Use the

show iptv rule all

command to view the rule id that the user matches. The user may match multiple rules, whose priority sequence is VLAN+port rule>port rule. View whether the channel or channel group that the rule allows its users to watch is correct. If no, reconfigure the

CAC

rule to grant the user the "order" privilege.

1

2

ZXR10(config)#show iptv rule all

Id Port Vlan Mode Service Cdr ViewNum PrwNum QryNum PkgNum

---- -------------- ---- ------- ------- ----- ------- ------ ------ -----gei-0/1/1/12 gei-0/1/1/11 channel IN channel IN

TRUE 1

TRUE 1

255

0

0

0

0

0

3-44



ZXR10(config)#show iptv rule port gei-0/1/1/11

RuleNo :2 Vlan :

CdrEnable

Mode

:TRUE

:channel

Port

Service

:gei-0/1/1/11

:IN_SERVICE

Max bandwidth :2048

Package number :0

View number :1

Channel id :0

Preview number :0

Query number :0 b.

Check whether the channel or channel group is configured correctly.

Use the

show iptv channel id

<channel-id>

command to view whether the group that is configured in the channel is the one that the user expects to order.

l If no, reconfigure the channel.

l

If the channel group is configured, use the

show iptv package id

<

package-id

> command to view whether the group that is configured in the channel group includes the one that the user expects to order.

If no, reconfigure the channel group.

ZXR10(config)#show iptv channel id-list 0

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

Channel Id

Mvlan

CdrEnable

:0

:4000

:TRUE

Name

GroupAddr

BlackoutInter

:CHNAME0

:225.0.0.0

:60

MaxPrwDuration :120

ViewProfileId :0

MaxPrwCount

BandWidth

:3

:0

ViewProfileName :DEFVAL

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

ZXR10(config)#show iptv package id 1

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

Package Id :1 Package Name:s1

3.

Check whether there is a limit on the number of channels that can be ordered simultaneously.

If the user is allowed to order only a limited number of channels, the number of the simultaneous channels that the user orders cannot exceed the maximum. Otherwise, the order can fail.


SJ-20150114102049-012|2015-01-15 (R1.0)

3-45



3.14 Troubleshooting Case: IPTV Users Switch Offline

Abnormally

Figure 3-23

shows that the

IPTV

function is enabled on the switch in this networking scenario to control user access. A user has ordered channel CH-1. However, the user goes offline abnormally after being online for some time.

Figure 3-23 IPTV Users Go Offline Abnormally

Figure 3-24

shows the troubleshooting procedure for the case that IPTV users go offline abnormally.

Figure 3-24 Troubleshooting Procedure Diagram for the Case that IPTV Users Go

Offline Abnormally

SJ-20150114102049-012|2015-01-15 (R1.0)

3-46



Steps

1.

Check whether the

CAC

rule is configured correctly.

The misconfiguration of a CAC rule may cause users' unexpected disconnection from the network. If the user is wrongly granted the preview privilege, the user can be online only for a limited period. The user only has a short time for the preview of the channel.

When the expiration time comes, the traffic of the channel will be cut off from the user.

Use the

show iptv cac-rule id

<

rule-id

> command to view whether the user is granted the "order" prividge for the channel he orders. If no, modify it to "order".

1

2

ZXR10(config)#show iptv rule all

Id Port Vlan Mode Service Cdr ViewNum PrwNum QryNum PkgNum

---- -------------- ---- ------- ------- ----- ------- ------ ------ -----gei-0/1/1/12 gei-0/1/1/11 channel IN channel IN

TRUE

TRUE

1

1

255

0

0

0

0

0

ZXR10(config)#show iptv rule port gei-0/1/1/11

RuleNo :2 Vlan :

CdrEnable

Mode

:TRUE

:channel

Port

Service

:gei-0/1/1/11

:IN_SERVICE

Max bandwidth :2048

Package number :0

View number

Channel id

:1

:0

Preview number :0

Query number :0

2.

Check whether the query agent function is enabled correctly.

When the IPTV funtion is enabled, the query agent function must be enabled globally and in all the users' VLANs because the query packets that are received from the multicast VLAN cannot be forwarded to the user's VLAN via other VLANs. Use the

show ip igmp snooping query

command to check whether the query agent function is enabled globally and in all the users' VLANs and whether the query interval is in a reasonable range (it is recommended to be shorter than the half of host-time-out).

ZXR10(config)#show ip igmp snooping query

IGMP Snooping querier is enabled.

IGMP Snooping Query Interval is 125s.

IGMP Snooping Query Response Interval is 10s.

IGMP Snooping querier is enabled in vlan 100.

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 enabled in this vlan.

IGMP Snooping fast-leave is disabled in this vlan.

3-47



IGMP Snooping acl is none in this vlan.

IGMP Snooping max group number is 1024 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 0 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 0 in this vlan.

S = Static; D = Dynamic.

Index VLAN Group ID Drop Prejoin MaxHostNum Ports

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

ZXR10(config)#

If the agent is not enabled or the interval is overlong, modify the values as follows:

ZXR10(config)#ip igmp snooping querier

ZXR10(config)#vlan 100

ZXR10(config-vlan100)#igmp snooping querier

ZXR10(config-vlan100)#exit

ZXR10(config)#ip igmp snooping query-interval 125

3.

Check whether the VOD client software on the host responds to the query correctly.

Excute the

debug igmpsnoop packet

command on the device to enable the debugging function. Wait for a query cycle (125 seconds by default) and then check the printed debugging messages to see whether the interface that the host is directly connected to receives the

IGMP

membership report packets. If there are no debugging messages, it indicates that the VOD client software on the host does not respond to the query or send membership report. Check the VOD client software on the host to ensure that it can repond to the query normally.

ZXR10#debug igmpsnoop packet

IGMPSNOOP packet debugging is on

ZXR10#

10:56:48 10/31/2012

IGMP SNOOPING Rcv 225.1.1.1 Group Report Msg: From Vlan 200, Port gei_0/1/1/1 .

SJ-20150114102049-012|2015-01-15 (R1.0)

3-48



Note:


no debug all



debug all



3.15 Troubleshooting Case: DHCP Client Fails to

Obtain an IP Address When being Connected to the DHCP Server Directly

Figure 3-25

shows that the

DHCP

client is directly connected to the DHCP server through the network cable. The client fails to obtain an IP address.

Figure 3-25 DHCP Client is Connected to the DHCP Server Directly

Figure 3-26

shows the troubleshooting procedure for the case that the DHCP client Fails to Obtain an IP Address When being Connected to the DHCP server Directly.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-49



Figure 3-26 Troubleshooting Procedure Diagram for the Case that DHCP Client Fails to

Obtain an IP Address When being Connected to the DHCP Server Directly

Steps

1.

Check whether the NIC (network interface card) of the DHCP client works normally.

3-50



Use the

ping 127.0.0.1

command on the DHCP client to check whether the NIC of the

DHCP client works normally. If the command gets the successful echo response, it indicates that the NIC of the client works normally.

2.

Check whether the link between the DHCP client and the DHCP server is ok.

Configure the IP address on the interface of the DHCP client manually. The segment of the IP address must be the same as that of the IP address on the Port 1 interface of the DHCP server.

Use the ping program to check the link connectivity between the DHCP client and the

DHCP server. If the DHCP client pings the IP address of the DHCP server successfully, it indicates that the link between them is ok, and the fault of the physical link and the ethernet card are excluded.

3.

Check whether the DHCP service is enabled globally.

Use the

show ip dhcp configure

command to check whether the DHCP service is enabled on the device. See the result as follows:

ZXR10#show ip dhcp configuration

DHCP process state information process state: enable(running) ramble state: disable suppress_nak state: disable max_hops: 4

DHCP server configure: server support max user: 64000 server update arp: off

DHCP relay configure: not insert relay option82 information in BOOTREQUEST.

relay option82 policy: replace relay option82 format: china-tel relay option82 user policy: interface relay support max user: 64000 relay update arp: off

If no, use the

enable

command in global mode to enable the DHCP service globally.

4.

Check whether the DHCP server function is enabled and the DHCP service policy is applied on the interface.

use the

show running-config dhcp

command to view the configuration information of the corresponding interface. If there is no

mode server

in the configuration, it indicates that the DHCP server function is not enabled on the interface.

If the DHCP server function is not enabled on the interface, use the

mode server

command in interface configuration mode to enable the DHCP server function on the interface.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-51



Use the


command to view the configuration information of the corresponding interface. If there is no

policy

<

policy name

>, it indicates that the

DHCP service policy is not applied on the interface.

Use the

policy

<policy name>

command in interface configuration mode to apply the corresponding DHCP service policy.

ZXR10#show running-config dhcp

!<dhcp> ip dhcp pool test ip-pool test

$ ip dhcp policy test 1 dhcp-pool test

$ dhcp enable interface vlan10 mode server policy test

$

$

!</dhcp>

5.

Check whether the DHCP IP address pool is configured correctly.

a.

Use the

show ip dhcp policy

<policy name>

command to view the existing binding relationship between the DHCP service policy and the DHCP IP address pool.

b.

Use the

show ip dhcp policy

<dhcp pool name>

command to view the binding relationship between the DHCP IP address pool and IP addresses.

c.

Use the

show ip local pool configure

<pool name>

command to view the IP address range of the configured IP address pool. Check whether the range is in the same network segment as the address of the interface that uses the pool. If the IP address range in the IP address pool is not set correctly, correct it according to the particular situation.

ZXR10(config)#show ip dhcp policy test

PolicyName test

Total: 1

Priority DhcpPool

1 test

RelayAgent Vrf-instance

ZXR10(config)#show ip dhcp pool test

PoolName IpPool LeaseTime DnsNum RouterNum OptionNum BindNum test test 0 1 0 0

ZXR10(config)#show ip local pool configure test

1 0 0

PoolName test

Total: 1

Begin

192.168.1.100

End

192.168.1.200

Mask

24

Free

101

Used

0

3-52



6.

Check whether there is an IP address available in the IP address pool.

Use the

show ip local pool

<pool name>

to view the number of the users that are online currently. If the number reaches the upper limit of users in the IP address pool, add IP addresses into the pool.

If the number of current users reaches the configured maximum number of users, modify the maximum number of users on the device.

ZXR10(config)#show ip local pool

PoolName Begin End test 192.168.1.100

192.168.1.200


Mask

24

Free

101

Used

0


Obtain an IP Address via DHCP Snooping

Figure 3-27

shows that

DHCP

(Dynamic Host Configuration Protocol) Client fails to obtain an IP address via DHCP Snooping.

Figure 3-27 DHCP Client Fails to Obtain IP Address via DHCP Snooping

Figure 3-28 shows the troubleshooting procedure for the case that the DHCP client fails to

obtain an IP address via DHCP Snooping.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-53



Figure 3-28 Troubleshooting Procedure Diagram

Steps

1.


Use the

ping 127.0.0.1


DHCP client works normally.If the command gets the successful echo response, it indicates that the NIC of the client works normally.

2.

Check whether the link between the DHCP client and the DHCP server is ok.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-54



On the DHCP client, manually configure an IP address on the ethernet interface via which the DHCP client is connected to the DHCP snooping device. The network segment of the IP address must be the same as that of the IP address of the DHCP server.

Use the ping program to check the link connectivity between the DHCP client and the DHCP server. If the DHCP client pings the IP address of the interface of the

DHCP server successfully, it indicates that the link between the DHCP client and DHCP

Snooping device is ok, and the link between the DHCP Snooping device and DHCP server is ok.

Note:

If such security control functions as the IP Source Guard and DAI are enabled on

DHCP Snooping device, the user needs to be added as statically bond user of the

DHCP Snooping. Otherwise, the manually configured IP address can be regarded as an illegal user and then be filtered. The statically bond user needs to be deleted after the test is completed.

3.

Check whether the DHCP service is enabled on the DHCP Snooping device.

Use the

show ip dhcp configuration

command to check whether the DHCP service is enabled on the device. See the result as follows:






If no, enter DHCP mode in global mode, and use the

enable

command to enable the

DHCP service globally.

4.

Check the configuration of the DHCP Snooping function.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-55


ZXR10 5900E Series Troubleshooting a.

Use the

show ip dhcp snooping configure

command to check whether the DHCP

Snooping function is enabled globally. See the result as follows:

ZXR10(config)#show ip dhcp snooping configure

DHCP snooping configure information

Global state :enable(running)

Mac-verifying state :disable

Not insert relay information in BOOTREQ UEST

Relay information policy :keep

Relay information format :china-tel

Support max user :2048

If no, use the

ip dhcp snooping enable

command in global mode to enable the

DHCP Snooping function on the DHCP Snooping device.

b.

Use the

show ip dhcp snooping vlan

command to check whether the DHCP

Snooping function is enabled in the VLAN that the DHCP client belongs to.

Snooping. See the result as follows:

ZXR10(config)#show ip dhcp snooping vlan

DHCP snooping state on vlans

Vlan State

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

1 disable

If no, use the

ip dhcp snooping enable

command in global mode to enable the

DHCP Snooping function in the corresponding VLAN.

c.

Use the

show ip dhcp snooping trust

command to view whether the DHCP

Snooping trust interface is configured correctly. See the result as follows:

ZXR10(config)#show ip dhcp snooping trust

Interface State

------------------------------------------gei_0/1/1/1 Trusted

If the displayed interface is not the one that connects DHCP server, modify it to the right interface.

5.

Check whether the remote DHCP server is configured correctly.

Check the remote DHCP server. If the DHCP server is the product of ZXR10 series

produced by ZTE, refer to " 3.15 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address When being Connected to the DHCP Server Directly

" to troubleshoot the fault in the DHCP server.


SJ-20150114102049-012|2015-01-15 (R1.0)

3-56




Obtain an IP Address via DHCP Relay

Figure 3-29

shows that the

DHCP

(Dynamic Host Configuration Protocol) client fails to obtain an IP address via DHCP Relay.

Figure 3-29 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via

DHCP Relay

Figure 3-30 shows the troubleshooting procedure for the case that the DHCP client fails to

obtain an IP address via DHCP Relay.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-57



Figure 3-30 Troubleshooting Procedure Diagram

Steps

1.


Use the

ping 127.0.0.1


DHCP client works normally.If the command gets the successful echo response, it indicates that the NIC of the client works normally.

2.

Check whether the link between the DHCP Client and the DHCP Relay is ok.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-58



On the DHCP client, manually configure an IP address on the ethernet interface via which the DHCP client is connected to the DHCP Relay. The network segment of the

IP address must be the same as that of the IP address of the DHCP Relay.

Use the ping program to check the link connectivity between the DHCP client and the

DHCP Relay. If the DHCP client pings the IP address of the interface of DHCP Relay successfully, it indicates that the link between them is ok.

3.

Check whether the link between the DHCP Relay and the DHCP server is ok.

Use the ping program on the DHCP Relay device to check the link connectivity between the DHCP Relay and the DHCP server. If the DHCP Relay pings the DHCP server successfully, it indicates that the link between them is ok and the route is reachable.

4.

Check whether the DHCP service is enabled on the DHCP Relay device.

Use the

show ip dhcp configure

command in system configuration mode on the DHCP

Relay device to check whether the DHCP service is enabled. See the result as follows:






If no, enter DHCP mode in global mode, and use the

enable

command to enable the

DHCP service globally.

5.

Check whether the relay interface of DHCP Relay device is configured correctly.

Use the


command to view the configuration of DHCP Relay interface.

a.

Check whether the interface configuration mode is relay, that is, whether there is

mode relay

in the interface configuration.

b.

Check whether the relay address and the relay service address are specified on the relay interface, that is, whether there are

relay agent

<A.B.C.D>

and

relay server

<

A.B.C.D

>

security

|

standard

in the interface configuration.

The relay address should be specified as the IP address of the interface on which the DHCP relay function is enabled.

3-59



The relay service address should be specified as the IP address of the interface of the DHCP server.

ZXR10(config)#show running-config dhcp

!<dhcp> ip dhcp relay server group 1 server 1 201.1.1.1 standard

$ dhcp enable interface vlan10 mode relay relay server group 1 relay agent 192.168.1.1

$

6.

Check whether the relay function of DHCP server is configured correctly.

If the DHCP server is the product of the ZXR10 series produced by ZTE, perform the following steps to troubleshoot the fault: a.

Check the configuration of the IP address pool on the DHCP server.The network segment of the IP address range configured in the IP address pool must be the same as that of the IP address of the the DHCP Relay's interface that connects users.

b.

Check the configuration of the DHCP servce policy on the DHCP server.Check

whether the DHCP relay function is configured in DHCP service policy, that is, whether

relay-agent

<

A.B.C.D

> exists and wheher the specified address is the IP address of the relay interface of the DHCP relay device.

c.

Check whether there is IP address availalbe in the IP address pool of the DHCP server.if no, extend the address range of the IP address pool.

ZXR10(config)#show ip dhcp policy test

PolicyName Priority DhcpPool test 1 test

RelayAgent

192.168.1.1

Vrf-instance

Total: 1

ZXR10(config)#show ip local pool

PoolName test

Total:1

Begin

192.168.1.100

End

192.168.1.200

Mask

24

Free

101

Used

0


3.18 Troubleshooting Case: Users of a Switch Fail to

Receive Traffic in PIM_SM Environment

Figure 3-31

shows that there is traffic group 225.0.0.0 in

PIM-SM

environment and multiple users have ordered the program. The PC A user that is connected to switch A (a

3-60


Chapter 3 Software Troubleshooting convergence center) receives the traffic normally, but the PC B user that is connected to switch B (another convergence center) fails to receive the traffic.

Figure 3-31 PIM-SM Networking

Figure 3-32

shows the troubleshooting procedure for the case that users of a Switch fail to receive traffic in PIM-SM environment.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-61



Figure 3-32 Troubleshooting Procedure Diagram for the Case that Users of a Switch

Fail to Receive Traffic in PIM-SM Environment

Steps

1.

Check whether the interface through which the user is connected to the center is in link-up state.

Make sure that the interface for user access is link-up. Otherwise, the service packets cannot be sent or received. Use the

show interface

<interface-name>

command to

view the current state of the interface. If it is down, refer to " 3.1 Troubleshooting Case:

Ports Fail to Work in Link-up State " for the troubleshooting solution.

3-62



ZXR10(config)#show interface gei_0/1/1/1 gei_0/1/1/1 is down, line protocol is down

Description is none


Duplex full

Mdi type:auto


Last clearing of "show interface" counters never

20 seconds input rate :

20 seconds output rate:

0 Bps,

19 Bps,

0 pps

0 pps

2.

Check whether the PIM-SM protocol is enabled globally and on interfaces.

Use the

show running-config


PIM-SM

protocol is enabled globally and on interfaces. If no, enable them by the method shown below:

ZXR10(config)#ip multicast-routing

ZXR10(config-mcast)#router pim

ZXR10(config-mcast-pim)#interface vlan13

ZXR10(config-mcast-pim-if-vlan13)#pimsm

ZXR10(config-mcast-pim-if-vlan13)#exit

3.

Check whether the IGMP Snooping is configured on outgoing VLAN.

Use the

show ip mroute group-address

<

ip address

> command to check whether there is outgoing entries in multicast routing/forwarding table. If no, use the

show running-c onfig


igmp snooping

is configured in this vlan. If no, configure

igmp snooping

in this vlan.

ZXR10(config)#show ip mroute group 225.0.0.0

IP Multicast Routing Table

Flags:NS:SPT upsend, RT:Reg upsend, MT:tunnel, F:Forward, S:Syn mrt,

NTP:NTP join, FLT:Flt add, FD:Flt del, DPU:Damping enable, DPD:Damping del,

B:Bidir

(*, 225.0.0.0), RP: 5.5.5.5, TYPE: DYNAMIC, FLAGS:

Incoming interface: vlan23, flags:

Outgoing interface list: vlan24, flags: F/S

ZXR10(config)#show running-config


...

!

vlan 13 igmp snooping

!

4.

Check whether the new membership report packets are received on the downstream interface.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-63



After the

igmp snooping

of the outgoing VLAN is verified to be configured correctly, check whether the new membership report packets are received on the downstream interface if there is no exit in the multicast routing table in the switch.

Use the

debug ip igmp

<

ip address

> command to enable the debugging function to check whether the new membership report packets are received correctly. If there is no printed debugging messages, it indicates that this interface does not receive the new membership report packets. Check the multicast software on the downstream node to ensure that it runs properly and has sent the IGMP membership report packets successfully.

ZXR10#debug ip igmp 225.0.0.0

IGMP permit group (225.0.0.2) debugging is on

ZXR10#ter m

ZXR10#ZXR10 MP-0/1/0 2010-1-2 23:52:57 IGMP : Received packet is IGMPv2 members hip report for group 225.0.0.0

ZXR10 MP-0/1/0 2010-1-2 23:52:57 IGMP : Updating EXCLUDE group timer for 225.0.

0.0 timer to 260 seconds

ZXR10 MP-0/1/0 2010-1-2 23:52:58 IGMP : Received packet is IGMPv2 membership re port for group 225.0.0.0

ZXR10 MP-0/1/0 2010-1-2 23:52:58 IGMP : Updating EXCLUDE group timer for 225.0.

0.0 timer to 260 seconds

ZXR10 MP-0/1/0 2010-1-2 23:52:59 IGMP : Received packet is IGMPv2 membership re port for group 225.0.0.0

5.

Check whether the multicast border

bsr-border

is wrongly configured.

Check whether the

bsr-border

is configured on upstream interface if the switch has received the new membership report packets correctly. Use the

show running-config multicast

command to view the configuration.

If yes, delete this

bsr-borde

configuration.

ZXR10(config-mcast-pim)#show running-config multicast

!<multicast> ip multicast-routing router pim bsr-candidate loopback1 rp-candidate loopback1 interface vlan13 pimsm bsr-border

$

$

$

!</multicast>


ZXR10(config-mcast-pim-if-vlan13)#no bsr-border

6.

Check whether the limit on new groups is configured.

3-64



Use the


command and the

show ipv4-access-lists name

<

acl-number


access-group

and

max-host-limit

are configured. Use the

show ip igmp groups summary

command to view the number of multicast groups that users have joined in. If the limit on new groups is configured, make sure that the new group is in the allowed range of ACL, and the number of groups that users have joined in does not exceed the

max-host-limit

.

ZXR10(config)#show running-config multicast

$ router igmp interface vlan13 access-group 1

$ max-host-limit group 225.0.0.0 limit-num 10

$

ZXR10(config)#show ipv4-access-lists name 1 ipv4-access-list 1

1/1 (showed/total)

1 permit 225.0.0.0 0.0.0.0

2 permit 225.0.0.1 0.0.0.0

ZXR10(config)#show ip igmp groups summary

IGMP groups summary:

Interface Static Joined Total vlan13

Summary

0

0

1

1

1

1


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

In

PIM-SM

environment, the RP information in the mapping from all devices to the specified group are not the same.

Figure 3-33

shows the troubleshooting procedure for this problem.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-65



Figure 3-33 Troubleshooting Procedure Diagram for the Case that RP Information is Wrong in

PIMSM Environment

Steps

1.

Check whether the RP is configured as static RP or dynamic RP.

When the RP information mapped in the specifical group on the devices is not the same, check whether the RP is configured as static RP or dynamic RP. Use the

show ip pim rp mapping

command and the

show ip pim rp hash

<group address>

command to check whether the RP is configured as static RP or dynamic RP.

ZXR10(config)#show ip pim rp mapping

Group(s) 224.0.0.0/4

RP 1.1.1.1, Static, Priority :192

RP 11.11.11.11, v2, Priority :192

BSR: 8.8.8.8, via bootstrap

Uptime: 16:09:04, expires: 00:01:50

3-66



ZXR10(config)#show ip pim rp hash 225.0.0.0

rp address:1.1.1.1

static

2.

Check whether the same static RPs are configured on all the switches.

If static RPs are configured on switches, all the static RPs on all the switches must be the same. Use the


command to view it.

ZXR10(config)#show running-config multicast router pim static-rp 1.1.1.1

3.

Check whether the group restriction is configured on static RPs.

If all the static RPs on all the devices are the same, check whether the group range is configured on static RPs. Use the


command and the


<

acl name

> command to view the group range information.

Make sure that the multicast group is within the allowed range of

ACL .

ZXR10(config)#show running-config multicast router pim static-rp 1.1.1.1 group-list 1


1/1 (showed/total)

1 permit 225.0.0.0 0.0.0.0

2 permit 225.0.0.1 0.0.0.0

4.

Check whether the unicast routes among the nodes are reachable.

Check whether the unicast routes among the nodes are reachable. Use the

show ip forwarding route

<

network address

> to check the route information on the specific network segment. If the route is unreachable, modify the configuration of the unicast routes.

ZXR10(config)#show ip forwarding route 8.8.8.8

IPv4 Routing Table:

Dest Gw Interface

*> 8.8.8.8/32 10.10.8.1

vlan8

Owner

OSPF

Pri Metric

110 2

5.

Check whether the group restriction is configured on C-RP.

Use the


command and the


<

acl name

> command to check whether the group restriction is configured on C-RP.

Make sure that the ordered group is within the allowed range of ACL.

ZXR10(config)#show running-config multicast router pim rp-candidate loopback2 group-list 1


1/1 (showed/total)

1 permit 225.0.0.0 0.0.0.0

3-67



2 permit 225.0.0.1 0.0.0.0

6.

Check whether the accept-rp is configured on BSR.

Use the


command and the


<

acl name


accept-rp

is configured on BSR.If yes, make sure that the IP address of RP is within the allowed range of ACL.

ZXR10(config)#show running-config multicast router pim accept-rp 1 bsr-candidate loopback1 priority 30


1/1 (showed/total)

1 permit 1.1.1.1 0.0.0.0


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

Figure 3-34

shows that in

PIM-SM

environment, the source fails to register. When the source sends the traffic of group 225.0.0.0, no multicast route entries are created on Switch

B, the RP.

Figure 3-34 PIM-SM Networking

Figure 3-35

shows the troubleshooting procedure for the case that the source fails to register in PIM-SM Environment.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-68



Figure 3-35 Troubleshooting Procedure Diagram for the Case that Source Fails to

Register in PIM-SM Environment

SJ-20150114102049-012|2015-01-15 (R1.0)

3-69



Steps

1.

Check whether the PIM-SM is configured on all the interconnected interfaces.

Use the



PIM-SM

is configured on all the interconnected interfaces. If no, configure the

PIM-SM

on these interfaces.

ZXR10(config)#show running-config multicast

!<multicast> ip multicast-routing router pim bsr-candidate loopback1 priority 70 rp-candidate loopback1 interface vlan8 pimsm

2.

Check whether the RP information is correct.

If the PIM-SM is configured on all the interconnected interfaces, check whether the RP information is correct next. Use the

show ip pim rp hash

<group address>

command to check whether the RP information of Switch B and the RP information in the mapping from the first-hop switch to the specified group are the same. If no, check the RP configuration. Refer to "

3.19 Troubleshooting Case: RP Information is

Wrong in PIM-SM Environment " for the detailted steps.

ZXR10(config)#show ip pim rp ha 225.0.0.0

RP address: 5.5.5.5

3.

Check whether the unicast routes among the nodes are reachable.

If the RP information is correct, check whether the unicast routes among the nodes are reachable next. Use the


<

network address

> to check the route information on the specifiied network segment. If the route is unreachable, modify the configuration of the unicast routes.


IPv4 Routing Table:

Dest

*> 8.8.8.8/32

Gw

10.10.8.1

Interface vlan8

Owner

OSPF

Pri Metric

110 2

4.

Check whether the bsr-border is configured on the RP's interface of the source side.

Use the



bsr-border

is configured on the RP's interface of the source side. If yes, cancel this configuration.


!<multicast> ip multicast-routing router pim bsr-candidate loopback1 rp-candidate loopback1 interface vlan8

3-70


Chapter 3 Software Troubleshooting pimsm bsr-border

$

$

$

!</multicast>



5.

Check whether the accept-register is configured on the RP.

If the

bsr-border

is not configured on the RP's interface of the source side, use the

sh ow running-config multicast

command and the


<

acl name

> to check whether the

accept-register

is configured on the RP.If yes, make sure that the IP address of the multicast source is within the allowed range of ACL.

ZXR10(config)#show running-config multicast router pim rp-candidate loopback1 accept-register 1


1/1 (showed/total)

1 permit 10.10.50.2 0.0.0.0

6.

Check whether there is multicast routing table in the first-hop switch.

If the configuration on the RP is verified to be correct, check the first-hop switch next.

First, make sure that there is multicast routing table in the first-hop switch. Use the

show ip mroute group

<group address>

to view the result. If there is no multicast route entries, check whether there are faults in the directly connected link between the first-hop switch and the multicast source.

ZXR10(config)#show ip mroute group 225.0.0.0

IP Multicast Routing Table

Flags:D -Dense,S -Sparse,C -Connected,L -Local,P -Pruned,

R -RP-bit set,F -Register flag,T -SPT-bit set,J -Join SPT,

M -MSDP created entry,N -No Used,U -Up Send,

A -Advertised via MSDP,X -Proxy Join Timer Running,

* -Assert flag

Statistic:Receive packet count/Send packet count

Timers:Uptime/Expires

Interface state:Interface,Next-Hop or VCD,State/Mode

(*, 225.0.0.0), 03:02:44/00:03:35, RP 0.0.0.0 , 0/0, flags: SP

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list: NULL

(10.10.50.2, 225.0.0.0), 02:55:50/00:03:35 , 49955/6655, flags: PT

Incoming interface: vlan50, RPF nbr 0.0.0.0

3-71



Outgoing interface list: NULL

7.

Check whether the first-hop switch can ping the source successfully.

If there is no multicast routing table in the first-hop switch, check whether the first-hop switch's interface of the source side and the source are in the same network segment.

Use the

ping

command on the switch to view whether the source address is reachable.

If no, check the IP addresses of the two interconnected interfaces respectively (one is the interface of the first-hop switch through which the switch is connected to the source, and the other is the interface of the source throught which the source is directly connected to the switch.). Set the IP addresses of the two interfaces and ensure that they are in the same network segment. Use the

show running-config interface vlan

<vlan_id>

command to view the IP addresses of the interfaces.

ZXR10(config)#show running-config interface vlan 50


!

interface vlan 50 ip address 10.10.50.1 255.255.255.0

out_index 33

8.

Check whether the RPF neighbor to the RP is correct.

Use the

show ip pim nexthop

command to check whether the RPF neighbor from the switch to the RP is correct. A RPF neighbor must be a PIM-SM neighbor. If a RPF neighbor is not a PIM-SM neighbor, use the

show ip pimsm neighbor

command to check whether a PIM-SM neighbor is set up between the interfaces of the switch and the RP.

If no, configure the

pimsm

on all the interfaces between the switch and the RP.

ZXR10(config)#show ip pim nexthop

PIM Nexthop Table

Nexthop state: R- Nexthop to RP,S- Nexthop to Source,

O- Related with Unicast,U- No Unicast Route,

L- Local Route,C- Connect to Dest,

Dest: 5.5.5.5

(00:03:25)

Type:.R. .O. . .

Metric:2

Preference:110

Ecmp list:

Nexthop: 10.10.8.1 (PIM neighbor 10.10.8.1)

Port:vlan8

ZXR10(config)#show ip pim neighbor

Neighbor Address Interface

10.10.8.1

vlan8

DR Priority

1

Uptime

00:11:37

Expires

00:01:36

Ver

V2

9.

Check whether the bsr-border is configured on the downstream interface of the first-hop switch.

3-72



If the RPF neighbor that the first-hop switch is led to the RP is correct, use the



bsr-border

is configured on the downstream interface of the first-hop switch. If yes, cancel this configuration.


!<multicast> ip multicast-routing router pim bsr-candidate loopback1 rp-candidate loopback1 interface vlan8 pimsm bsr-border

$

$

$

!</multicast>




3.21 Troubleshooting Case: Anycast RP Works

Abnormally in MSDP Environment

Figure 3-36

shows that in

MSDP

environment, there is no exchange of normal (s,g) information between Switch C and Switch D that are configured as anycast RP devices.

Figure 3-36 MSDP Networking Environment

Figure 3-37

shows the troubleshooting procedure for the case that anycast RP works abnormally in MSDP environment.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-73



Figure 3-37 Troubleshooting Procedure Diagram for the Case that Anycast RP Works

Abnormally in MSDP Environment

Steps

1.

Check whether the MSDP peers are reachable to each other in unicast.

First, check whether the addresses between MSDP peers on the two devices are reachable to each other in unicast. If no, the TCP connection cannot be established.

Use the


<

ip address

> command to check whether there is a unicast route leading to each other.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-74




IPv4 Routing Table:

Dest Gw Interface

*>8.8.8.8/32 10.10.12.2

vlan12

Owner

OSPF

Pri Metric

110 2

2.

Check whether the same RP addresses are configured.

If the MSDP peers are reachable to each other in unicast, use the


command and the

show ip interface loopback

<number>

command to check whether the same

anycast RP

addresses are configured on the two devices. If the anycast RP addresses are not the same, set them to the same address.

ZXR10(config)#show running-config multicast router pim bsr-candidate loopback1 rp-candidate loopback2

ZXR10(config)# sho ip interface loopback2 loopback2 AdminStatus is up, PhyStatus is up, line protocol is up, IPv4 protocol is up

Internet address is 11.11.11.11/32

Broadcast address is 255.255.255.255

Address determined by setup command

Load-sharing bandwidth 8000000 Kbps

IP MTU 1500 bytes

3.

Check whether the MSDP peers are established successfully.

If the anycast RP addresses are configured the same on the two devices, use the

show ip msdp peer

<ip address>

command to check whether the MSDP peers are established successfully. If no, view the

connection source

configuration. If the

MSDP peer is a loopback interface, the local loopback interface is required to be used to connect the peer; if MSDP peer is an ordinary Layer 3 interface, the local ordinary

Layer 3 interface is required to be used to connect the peer.

ZXR10(config)#show ip msdp peer 8.8.8.8

MSDP Peer 8.8.8.8

Description:

Connection status:

State: Up, Resets: 4, Connection source: loopback1 (5.5.5.5)

Uptime(Downtime): 02:49:48, Messages sent/received: 180/177

Connection and counters cleared 02:59:37 ago

SA Filtering:

Input (S,G) filter: none

Output (S,G) filter: none

Peer ttl threshold: 0

Peer ttl security hops: 0

SAs learned from this peer: 1

ZXR10(config)#show ip msdp peer 10.10.12.1

MSDP Peer 10.10.12.1

3-75



Description:

Connection status:

State: Up, Resets: 0, Connection source: vlan12 (10.10.12.2)

Uptime(Downtime): 00:00:01, Messages sent/received: 1/1

Connection and counters cleared 00:00:09 ago

SA Filtering:

Input (S,G) filter: none

Output (S,G) filter: none

Peer ttl threshold: 0

Peer ttl security hops: 0

SAs learned from this peer: 0

4.

Check whether the correct originator-id is configured on the two RPs.

If the establishment of MSDP peer is successful, use the


command to check whether the correct

originator-id

is configured on the two RPs.

The correct configuration must include originator-id. Make sure that the configured

originator-id

and

anycast RP

address are different.

ZXR10(config)#show running-config multicast router msdp originator-id loopback1 peer 10.10.12.1

connect-source vlan12

5.

Check whether the sa-filter is configured on the two RPs.

If the originator-id is configured correctly on the two devices, use the

show running

-config multicast


sa-filter

is configured on the two

RPs.If the legal peer addresses are filtered due to the wrong configuration, delete this configuration.

ZXR10(config)#show running-config multicast router msdp originator-id vlan12 peer 5.5.5.5

connect-source vlan12 sa-filter in list 5.5.5.5

ZXR10(config-mcast-msdp-peer)#no sa-filter in

6.

Check whether the sa-limit is configured on the two RPs.

Use the



sa-limit

is configured on the two RPs. If yes, make sure that the current online

sa entries

does not exceed the configured threshold.

ZXR10(config)#show running-config multicast router msdp originator-id vlan12 peer 5.5.5.5

connect-source loopback1

3-76


Chapter 3 Software Troubleshooting sa-limit 10

ZXR10(config)#show ip msdp sa-cache

MSDP Source-Active Cache - 2 entries

Timers:Uptime/Expires

(10.0.0.2, 239.169.162.1), RP 1.1.1.1, 04:49:59/00:05:38

(90.0.0.2, 239.169.162.1), RP 3.3.3.3, 04:49:59/00:05:38


3.22 Troubleshooting Case: System CPU Overload

Alarm

If services are interrupted abnormally, you need to use the

show processor

command to check the system

CPU

usage. When CPU usage is greater than 80%, the following system

CPU overload alarm is displayed:

ZXR10#show processor

============================================================================

============================================================================

M : Master CPU

S : Slave CPU

Power : Power dissipation (Watt)

CPU(5s): CPU utility measured in the last 5 seconds

CPU(1m): CPU utility measured in 1 minute

CPU(5m): CPU utility measured in 5 minutes

Peak : CPU peak utility measured in 1 minute

PhyMem : Physical memory (Megabyte)

FreeMem: Free memory (Megabyte)

Mem : Memory usage ratio

============================================================================

============================================================================

Shelf Panel CPUID Power CPU(5s) CPU(1m) CPU(5m) Peak PhyMem FreeMem Mem

============================================================================

MP(M) 0 1 0 N/A 11% 12% 11% 17% 2048 681 66.731%

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

ZXR10#

An alarm 500401 ID 34 level 3 occurred at 4:46:02 1-1-2010 sent by 36TM-59

MP-0/1/0 %CHM% utilization alarm!

Shelfnum =0 slot =1 dev_type =1 dev_num=1 describe=cpu[0] utilization overflow!

An alarm 500401 ID 34 level 3 cleared at 4:49:41 1-1-2010 sent by 36TM-59

MP-0/1/0 %CHM% utilization alarm!

Shelfnum =0 slot =1 dev_type =1 dev_num=1 describe=cpu[0]utilization overflow cancel

Figure 3-38

shows the troubleshooting procedure for the case that the system CPU overloads.

3-77



Figure 3-38 Troubleshooting Procedure Diagram for System CPU Overload Alarm

Steps

1.

Check CPU usage.

Use the

show processor details

command to check the detailed information about CPU usage. Record the time periods when CPU usage is greater than 80%.

ZXR10#show processor details

M: Master processor

S: Slave processor

PeakCPU: CPU peak utility measured in 1 hour

AveCPU: CPU average utility measured in 1 hour

Ticks: Ticks when CPU gets PeakCPU

PeakTime: Date and time when CPU reaches PeakCPU

=========================================================================

=========================================================================

Shelf Panel Hours AveCPU PeakCPU Ticks PeakTime

=========================================================================

NP

:1

0 1 1 11 87 4646 0:0:46 2010:1

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

0 1 2 11 12 564163 1:34:1 2010:1

:1

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

0 1 3 11 12 835970 2:19:19 2010:

1:1

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

3-78



0 1 4 11 12 1214277 3:22:22 2010:

1:1

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

0 1 5 16 96 1720787 4:46:47 2010:

1:1

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

2.

View statistical information about control plane security to check whether there are exceptional packet attacks.

Use the

show packet-statistic

<

interface name

> commands to view statistical information about control plane security of the each physical ports.

If the

PacketsPass

value of a protocol increases quickly, or the

PacketsDrop

value of a protocol is not 0, the port is attacked by the packets of the protocol. Record the protocol type and port of the attack source.

8

9

10

11

5

6

7

12

13

14

15

16

20

21

22

23

17

18

19

24

25

0

1

2

3

4

ZXR10#show packet-statistic gei-0/1/1/1

!<PACKETS STATISTIC INFO>

Type ProtocolName PacketsPass PacketsDrop

=============================================== v4_bgp_sp v4_bgp_dp v6_bgp_sp v6_bgp_dp v4_ospf

0

0

0

0

0

0

0

0

0

0 v6_ospf

V4_isis v6_isis rip v4_pim v6_pim igmp v4_ldp_tcp v4_ldp_udp v6_ldp_tcp v6_ldp_udp v4_rsvp v4_telnet v6_telnet v4_snmp ssh v4_super_telnet v6_super_telnet v4_http ntp_pkt ftp_20

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

3-79


ZXR10 5900E Series Troubleshooting ftp_21 v4_bfd_3784 v4_bfd_4784 v4_icmp v6_icmp v6_mld_mp v6_mld_np v6_rs v6_ra v6_ns v6_na v4_tacas_sport v4_tacas_dport v4_radius_1812 v4_radius_1813 dhcp_67 dhcp_68 v6_dhcp_546 v6_dhcp_547 v4_lspping v6_lspping vrrp vrrp_arp arp_request arp_reply group_mng vbas_pkt ttl = 1 msdp_sport msdp_dport v6 hop = 1 v4_bpdu v4_mutilcast v6_mutilcast mac_ping ipsec_4500 ipsec_500 l2pt v4_ptp_uni_319 v4_ptp_uni_320

V4_ptp_0180

V4_ptp_011B

UDLD

LLDP

DOT1X

46

47

48

49

43

44

45

50

51

52

53

54

34

35

36

37

31

32

33

26

27

28

29

30

38

39

40

41

42

67

68

69

70

62

63

64

65

66

58

59

60

61

55

56

57

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

SJ-20150114102049-012|2015-01-15 (R1.0)

3-80

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0



79

80

81

82

76

77

78

71

72

73

74

75

83

84

85

86

87 v6_tacas_sport v6_tacas_dport v6_radius_1812 v6_radius_1813 v6_ntp_pkt v6_ftp_20 v4_tftp v6_tftp v6_bfd_3784 v6_bfd_4784 v4_l2tp v6_vrrp v6_snmp isis2 lacp cfm cfm_normal

91

92

93

94

88

89

90 eaps efm sflow loopdet bfd tcp_data macping_np

95

96

97

98

99 l2pt_up l2pt_down

MAD ttl=0 reason_ttl=1

100 L3MTU

101 pkt_unknow

102 mpls

103 v6_ripng 0

!</PACKETS STATISTIC INFO>

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

3.

Use the

cpu-guard

command to limit the receiving rate of the attack packets.

To decrease CPU usage, use the

cpu-guard pp interface

<

interface name

>

rate mo de

<

protocol

><

rate

> command to limit the receiving rate of the attack packets. The corresponding protocol packet types of the groups are as follows. It is recommended that you set the rate to 10 pps.

ZXR10(config)#cpu-guard pp interface gei-0/1/1/1 rate mode ?

arp ARP protocol arp-vrrp bpdu dot1x

ARP-VRRP protocol

BPDU protocol

DOT1X protocol

3-81


ZXR10 5900E Series Troubleshooting isis2 lacp lldp mac-ping mld msdp ntp ptp radius snmp ssh tacacs group-mng Group manage icmp ICMP protocol igmp IGMP protocol ipv4-bgp IPv4 BGP protocol ipv4-dhcp IPv4 DHCP protocol ipv4-ldp IPv4 LDP protocol ipv4-ospf IPv4 OSPF protocol ipv4-pim IPv4 PIM protocol ipv4-rip ipv6-bgp

IPv4 RIP protocol

IPv6 BGP protocol ipv6-dhcp IPv6 DHCP protocol ipv6-ldp IPv6 LDP protocol ipv6-nd IPv6 ND protocol ipv6-ospf IPv6 OSPF protocol ipv6-pim IPv6 PIM protocol ipv6-rip isis

IPv6 RIP protocol

ISIS protocol telnet ttl udld untrust vbas vrrp

ISIS2 protocol

LACP protocol

LLDP protocol

MAC-PING ISIS protocol

MLD protocol

MSDP protocol

NTP protocol

PTP protocol

RADIUS protocol

SNMP protocol

SSH protocol

TACACS protocol

TELNET protocol

TTL protocol

UDLD protocol

UNTRUST protocol

VBAS protocol

VRRP protocol

4.

Locate the attack source.

Enable the corresponding debugging switch to view detailed information about the attack packets based on the protocol type and port of the attack source recorded in

Step 2. Locate the attack source based on the log information, such as port, MAC address, and IP address. Remove the attack source.

After removing the attack source, use the

cpu-guard pp interface

<

interface name

>

rate mode

<

protocol

><

rate

> command to restore the default rate; or record the debugging information, and seek technical support.

SJ-20150114102049-012|2015-01-15 (R1.0)

3-82



ZXR10#debug dhcp packet interface vlan1001

ZXR10#

1d17h DHCPM:receive switch packet with init phy_n gei-0/1/1/1

1d17h DHCPM:receive switch packet with LLC result phy_n gei-0/1/1/1

1d17h DHCPM:dev 0 npc 1 receive switch broadcast packet - gei-0/1/1/1 vlan 1001 vpn 0

1d17h DHCPM:receive switch DHCPDISCOVER packet[0000.0100.0002]

1d17h DHCPM:switch snooping vlan 1001 enable for request

1d17h DHCP SNOOPING: gei-0/1/1/1 receive DHCPDISCOVER[0000.0100.0002]!

1d17h DHCP SNOOPING:send DHCPDISCOVER from 0.0.0.0 to 255.255.255.255

1d17h DHCPM:vlan1001 is not in dhcp access mode[0000.0100.0002]!

1d17h DHCPM:receive switch packet with init phy_n gei-0/1/1/1

1d17h DHCPM:receive switch packet with LLC result phy_n gei-0/1/1/1

1d17h DHCPM:dev 0 npc 1 receive switch broadcast packet - gei-0/1/1/1 vlan 1001 vpn 0

1d17h DHCPM:receive switch DHCPDISCOVER packet[0000.0100.0002]

1d17h DHCPM:switch snooping vlan 1001 enable for request

1d17h DHCP SNOOPING: gei-0/1/1/1 receive DHCPDISCOVER[0000.0100.0002]!

1d17h DHCP SNOOPING:send DHCPDISCOVER from 0.0.0.0 to 255.255.255.255

1d17h DHCPM:vlan1001 is not in dhcp access mode[0000.0100.0002]!

ZXR10#

When using the debugging function, enable the correct debugging switch.

For example, the

debug dhcp all

command enables the DHCP debugging switch for the entire device, and the

debug dhcp packet interface vlan1001

command enables the

DHCP debugging switch for vlan1001. If gei-0/1/1/1 belongs to vlan1001, use the

debug ip dhcp vlan1001

command to enable the DHCP debugging switch for vlan1001 only.

After the fault is removed, use the

no debug all

command promptly to stop debugging and prevent the system resources from being occupied by the debugging process.

For a device that is operating on the network, it is prohibited to use

debug all

the command to enable all debugging switches.


SJ-20150114102049-012|2015-01-15 (R1.0)

3-83




SJ-20150114102049-012|2015-01-15 (R1.0)

3-84


Figures

Figure 2-1 General Procedure for Hardware Fault Troubleshooting........................... 2-1

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

Figure 3-2 Troubleshooting Procedure Diagram for the Case that Ports Fail to

Work in Link-up State.............................................................................. 3-2

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

Link......................................................................................................... 3-5

Figure 3-4 Troubleshooting Procedure Diagram for Lost Packets during Flow

Forwarding over the Link......................................................................... 3-5

Figure 3-5 Troubleshooting STP Loop Storm ............................................................ 3-9

Figure 3-6 Troubleshooting Procedure Diagram for STP Loop Storm ........................ 3-9

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

STP Topology Structure ........................................................................ 3-12

Figure 3-8 Troubleshooting Case: Multiple Devices Fail to Work Well Together in the Same MSTP Domain ...................................................................... 3-16

Figure 3-9 Troubleshooting Procedure Diagram for the Case that Multiple Devices

Fail to Work Well Together in the Same MSTP Domain......................... 3-16

Figure 3-10 Troubleshooting Procedure Diagram for the Case that STP Designated

Port is in a Continuous State of Discard *.............................................. 3-20

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

Figure 3-12 Troubleshooting Procedure Diagram for the Case that ZESR Ring

Network Fails to be in Up State............................................................. 3-22

Figure 3-13 VRRP Networking ................................................................................ 3-24

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

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

Group State Fluctuates Repeatedly ...................................................... 3-29

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

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

Partly Fails............................................................................................ 3-32

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

Figure 3-19 Troubleshooting Procedure Diagram for the Case that IGMP Snooping

User Fails to be Online ......................................................................... 3-37

Figure 3-20 Troubleshooting Procedure Diagram for Unsmooth Programs When being Viewed ........................................................................................ 3-41

Figure 3-21 IPTV Users Fail to Use the VOD Function............................................ 3-43

I



Figure 3-22 Troubleshooting Procedure Diagram for the Case that IPTV Users Fail to Use the VOD Function ...................................................................... 3-44

Figure 3-23 IPTV Users Go Offline Abnormally ....................................................... 3-46

Figure 3-24 Troubleshooting Procedure Diagram for the Case that IPTV Users Go

Offline Abnormally ................................................................................ 3-46

Figure 3-25 DHCP Client is Connected to the DHCP Server Directly ...................... 3-49

Figure 3-26 Troubleshooting Procedure Diagram for the Case that DHCP Client

Fails to Obtain an IP Address When being Connected to the DHCP

Server Directly ...................................................................................... 3-50

Figure 3-27 DHCP Client Fails to Obtain IP Address via DHCP Snooping............... 3-53

Figure 3-28 Troubleshooting Procedure Diagram.................................................... 3-54

Figure 3-29 Troubleshooting Case: DHCP Client Fails to Obtain an IP Address via

DHCP Relay ......................................................................................... 3-57

Figure 3-30 Troubleshooting Procedure Diagram.................................................... 3-58

Figure 3-31 PIM-SM Networking ............................................................................. 3-61

Figure 3-32 Troubleshooting Procedure Diagram for the Case that Users of a

Switch Fail to Receive Traffic in PIM-SM Environment .......................... 3-62

Figure 3-33 Troubleshooting Procedure Diagram for the Case that RP Information is Wrong in PIMSM Environment........................................................... 3-66

Figure 3-34 PIM-SM Networking ............................................................................. 3-68

Figure 3-35 Troubleshooting Procedure Diagram for the Case that Source Fails to

Register in PIM-SM Environment .......................................................... 3-69

Figure 3-36 MSDP Networking Environment ........................................................... 3-73

Figure 3-37 Troubleshooting Procedure Diagram for the Case that Anycast RP

Works Abnormally in MSDP Environment ............................................ 3-74

Figure 3-38 Troubleshooting Procedure Diagram for System CPU Overload

Alarm .................................................................................................... 3-78

SJ-20150114102049-012|2015-01-15 (R1.0)

II


Glossary

ACL

- Access Control List

ARP

- Address Resolution Protocol

BPDU

- Bridge Protocol Data Unit

CAC

- Channel Access Control

CPU

- Central Processing Unit

DHCP

- Dynamic Host Configuration Protocol

IEEE

- Institute of Electrical and Electronics Engineers

IGMP

- Internet Group Management Protocol

IPTV

- Internet Protocol Television

LDP

- Label Distribution Protocol

LSP

- Label Switched Path

LSR

- Label Switch Router

MAC

- Media Access Control

MPLS

- Multiprotocol Label Switching

MSDP

- Multicast Source Discovery Protocol

MSTP

- Multiple Spanning Tree Protocol

PIM-SM

- Protocol Independent Multicast - Sparse Mode

III



STP

- Spanning Tree Protocol

UPS

- Uninterruptible Power Supply

VFI

- Virtual Forwarding Instance

VPLS

- Virtual Private LAN Service

VRRP

- Virtual Router Redundancy Protocol

ZESR

- ZTE Ethernet Switch Ring

SJ-20150114102049-012|2015-01-15 (R1.0)

IV


ZXR10 5900E Series

ZXR10 5900E Series

Easy-Maintenance MPLS Routing Switch

Troubleshooting

LEGAL INFORMATION

Revision History

Contents

About This Manual

Chapter 1

Troubleshooting Overview

1.1 Fault Classification

1.2 Troubleshooting Methods

1.3 Emergency Help

Chapter 2

Hardware Troubleshooting

2.1 Power Troubleshooting

2.2 Fans Troubleshooting

2.3 Ports Troubleshooting

Chapter 3

Software Troubleshooting

3.1 Troubleshooting Case: Ports Fail to Work in

Link-up State

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

3.3 Troubleshooting Case: STP Loop Storm

3.4 Troubleshooting Case: State of STP Topology

Structure Keeps Fluctuating

3.5 Troubleshooting Case: Multiple Devices Fail to

Work Well Together in the Same MSTP Domain

3.6 Troubleshooting Case: STP Designated Port is in a

Continuous State of Discard

3.7 Troubleshooting Case: ZESR Ring Network Fails to be in Up State

3.8 Troubleshooting Case: Dual Devices are in Master

State in the VRRP Backup Group

3.9 Troubleshooting Case: VRRP Backup Group State

Fluctuates Repeatedly

3.10 Troubleshooting Case: ARP Learning Partly Fails

3.11 Troubleshooting Case: IGMP Snooping User Fails to be Online

3.12 Troubleshooting Case: The Program Fails to Play

Smoothly When being Viewed by Users.

3.13 Troubleshooting Case: IPTV Users Fail to Use the

VOD Function

3.14 Troubleshooting Case: IPTV Users Switch Offline

Abnormally

3.15 Troubleshooting Case: DHCP Client Fails to

Obtain an IP Address When being Connected to the DHCP Server Directly

3.16 Troubleshooting Case: DHCP Client Fails to

Obtain an IP Address via DHCP Snooping

3.17 Troubleshooting Case: DHCP Client Fails to

Obtain an IP Address via DHCP Relay

3.18 Troubleshooting Case: Users of a Switch Fail to

Receive Traffic in PIM_SM Environment

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

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

3.21 Troubleshooting Case: Anycast RP Works

Abnormally in MSDP Environment

3.22 Troubleshooting Case: System CPU Overload

Alarm

Figures

Glossary

Related manuals

ZTE

ZXR10 5900E Series

ZTE

ZXR10 5900E Series

Motorola

BSR 64000

ZTE

ZXCLOUD R5300 G3

ZTE

Q78-1800-2SW

Table of contents