How to locate the cause of a mirroring failure on an S series switch

14

If mirroring fails on an S series switch (except the S1700), locate the cause by referring to Fault Locating Guide-Software Troubleshooting-Mirroring.
If you have no access permission, contact Huawei technical support personnel.

Other related questions:
How can I check whether a loop exists on an S series switch
The simplest way to check the existence of a loop on an S series switch (except the S1700) is to check whether a MAC address flapping alarm exists on the switch. If the alarm exists, you can quickly locate the loop based on the information in the alarm. Run the display mac-address flapping record command to check whether MAC address flapping exists, or run the display trapbuffer command to check whether the alarm contains The mac-address has flap value or MAC move detected. For more information, visit Layer 2 Loop Troubleshooting.

CE series switches have high CPU usage, then how to quickly locate the cause and collect CPU information
If the CPU usage of the device is high, perform the following steps to locate and collect information, and then send the information to Huawei technical support personnel. 1. Run the display cpu command to view the services with the high CPU usage. display cpu CPU utilization statistics at 2016-02-02 02:07:22 366 ms System CPU Using Percentage : 6% CPU utilization for five seconds: 6%, one minute: 6%, five minutes: 6%. Max CPU Usage : 38% Max CPU Usage Stat. Time : 2016-02-01 12:29:26 821 ms State: Non-overload Overload threshold: 90%, Overload clear threshold: 75%, Duration: 480s --------------------------- ServiceName UseRate --------------------------- SYSTEM 6% AAA 0% ARP 0% CMF 0% ...... 2. Run the display system service service-name command repeatedly in the diagnostic view to check the service components with the high CPU usage. system-view [~HUAWEI] diagnose [~HUAWEI-diagnose] display system service SYSTEM Service : SYSTEM -------------------------------------------------------------------------------- Component CID CGID Process HaState CpuUsage MemUsage -------------------------------------------------------------------------------- DFS 0x81DE271D 0x1DE271B 10003 PRIMARY 0% 4006312 TELC 0x8091271F 0x91271D 10001 PRIMARY 0% 19000 SSHC 0x80922720 0x92271E 10001 PRIMARY 0% 41208 SSHS 0x80932723 0x932721 10001 PRIMARY 0% 48844 3. Run the display system thread process process-id command repeatedly in the diagnostic view to check the processes with the high CPU usage. system-view [~HUAWEI] diagnose [~HUAWEI-diagnose] display system thread process 10003 Info: This operation needs several seconds. Info: Operating, please wait for a moment......done. ------------------------------------------------------------------------------- Process ID Thread ID Thread Type BindComp BindCpu BindFlag Usage ------------------------------------------------------------------------------- 10003 1210525456 main thread Bind all Free 0% 10003 1227637888 DefSch0200 Free all Free 0% 10003 1227506816 IPC0000 Free all Free 0% 10003 1227768960 DefSch0300 Free all Free 0% 10003 1237476480 DefSch0100 Free all Free 0% 10003 1237607552 DefSch0101 Free all Free 0% 10003 1226847360 DMS_PIPE_RECV_TASK Free all Free 0% 10003 1218028672 TICK Free all Free 0% 10003 1226716288 DMS_TIPC_SEND Free all Free 0% 10003 1217766528 BOX_Out Free all Free 0% 10003 1217897600 VCLK Free 0 Free 0% 10003 1237738624 CliGetThreadCpu Free all Free 0% ------------------------------------------------------------------------------- Total = 12 4. Run the display system thread callstack process process-id thread-id command in the diagnostic view to check process call stack information. system-view [~HUAWEI] diagnose [~HUAWEI-diagnose] display system thread callstack process 10003 1210525456 Thread 1210525456 (Thread MainThread): #00 libc.so.6(epoll_wait) #01 location(Frame_FdMainThread) #02 location(Frame_Main) #03 location(main) #04 libc.so.6() #05 libc.so.6()

What are the possible causes for SSH and TACACS authentication failure on S series switches
For S series switches (except S1700 switches), SSH and TACACS authentication failure is commonly caused by no default authentication mode for SSH users. If no authentication mode is specified for SSH users, users cannot access the Internet through SSH. To solve the problem, run the ssh authentication-type default password command to configure password authentication for SSH users when configuring SSH authentication.

How to locate the ping failure
When the ping operation fails, locate the fault based on the following troubleshooting roadmap: 1. Check whether the AR interface is Up and whether the IP address is configured correctly. Command: display interface brief and display ip interface [ < interface-type > < interface-number > ] 2. If a Layer 2 interface is used, check whether STP is running on the AR and check whether the physical interface where ping packets pass is blocked. Command: display stp [ instance < instance-id > ] [ interface < interface-type > < interface-number > ] [ brief ] 3. Check whether routes are reachable: If routes are unreachable, troubleshoot the fault. Command: display ip routing-table 4. Check whether policies are configured on local and remote devices. If the remote device is a firewall, check whether the remote interface is added to a zone and whether the inter-zone rule is enabled. 5. Check whether ARP entries of the direct route are learned correctly. If ARP entries cannot be learned, check whether strict ARP learning is enabled. Disable strict ARP learning and try again. If the fault persists, perform the ping operation on one device and check whether ARP request packets are sent out from the interface and whether the remote device sends ARP reply packets based on ARP packet statistics. Commands: display arp and display arp learning strict 6. If there is no preceding problem, collect statistics on ICMP packets, determine the position where packets are lost and locate the packet loss point.

Locate an OSPF fault on an S series switch
You can run the debugging ospf event command on S series switches supporting OSPF to locate most faults. If an OSPF fault cannot be located using this command, run the debugging ospf packet command to enable OSPF packet debugging and check whether OSPF packets are sent and received normally according to debugging information. Note: The debugging commands are used for fault location. Exercise caution when using the commands.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top