Did you get chance to check on the physical layer issue on the interfaces on switch 3020 ,can you validate the speed and duplex setting on the interfaces.try to configure it manually,as full duplex  and speed 10/100/1000.See if interface comes up .   https://www.cisco.com/c/en/us/td/docs/switches/blades/3020/software/release/12-2_55_se/configuration/guide/3020_scg/swint.html#wp1025996%0A   Thanks, Naveen   ... View more

Hi , High cpu is due to Interrupt. Core#remote command switch-id 1 module 5 show process cpu CPU utilization for five seconds: 98%/83%; one minute: 97%; five minutes: 97%  PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process From the logs i could see STP is stable,NO TCN's observred. VLAN0007 is executing the rstp compatible Spanning Tree protocol   Number of topology changes 158 last change occurred 5w2d ago           from Port-channel111 From Netdr i could see, below are the  top talkers  , We see source 0000.0800.0000 and 0000.0300.0000 both are from Xerox cop mac addresses.Which are hitting to the CPU 0100.0ccc.cccc is used as a destination address for CDP, VTP and DTP. L2 Source Mac Value                    Count 0000.0800.0000    1487 0000.0300.0000    1233 000003    Xerox Corporation Kindly look into these source mac address ,try to find those interfaces which this source are connected to  and shut it down and look if the cpu get reduced. Regards, Naveen ... View more

Hi Mishaal, As we know CPU is due to interrupts and all traffic coming on vlan 55 and vlan4 which is getting punted to CPU. ++ We need to check below things ++ what is destination ip, does it belong to router? Is packet destined to router ++ Any feature applied on interface which is forcing traffic to get process switched. ++  Is all traffic coming on that vlan getting processed switched or only few packets? ++ All the time traffic getting punted or only when traffic exceeding a particular rate. ++ Is any copp applied? ++ Since when CPU is high, MRTG graph for CPU and interface utilization may help ++ An ELAM capture can also help here. ++ We need to perform extensive webex troubleshooting here ,can you open a SR to further investigate on this . Common scenario when traffic gets punted to CPU 1. TTL=1 2. Destination not in routing table 3. Packet destined to router 4. A feature applied on ingress or egress interface causing packet to be process switched 5. A field set on the packet which is not supported in hardware and requires process switching. Regards, Naveen Venkateshiah. ... View more

This is repeated question,as we are discussing above on the same. ... View more

Hi Vasanth, yes,  The switch fails to respond if there is high cpu utilization ,so since the cpu is high when you ping you may get request time out. Look for Topology change notifications (TCN): show spanning details | in executing|changes|from show spann det | in ieee|from|occur|is exec Regards, Naveen Venkateshaiah. ... View more

Hi Mishaal, If we  look at the netdr capture, Out of 4k packets more than 2k are for srcmac 00.22.A1.10.47.55 and now most of the destination is 84.235.x.x 2k packets,need to check  where is this destination? what is the mls config for this destination? These are the destination ip IPV4 packets sorted based on Dest IPv4 Address                                       Number of Packets 195.94.31.106                                                         996 195.94.31.107                                                         725  84.235.58.4                                                            336  84.235.60.231                                                        306  84.235.58.20                                                          241  84.235.44.244                                                        209  84.235.60.215                                                        204  This traffic is a L2 traffic, and we should forward in hardware,I am not expecting to see them here,but we need the full config, then show mls cef in order to understand the hardware config.  For these destination , packet is going to CPU,its not getting Hardware switched ,following link will provide you an idea on common reason why the packets are  being software switched rather than hardware switched.  https://supportforums.cisco.com/document/59926/troubleshooting-high-cpu-6500-sup720 Let me know if you have any further questions, also  capture this commands for above destination ip. Show run show ip cef sh mls cef <destination ip >detail sh mls cef adjacency entry show ip route <destination ips> show mls cef  lookup destination_ip_network detail show ip cef destination_network Regards, Naveen Venkateshaiah ... View more

Hi Mishaal, Thanks for the logs,from netdr we see from the below source the packets are punted to CPU continuously. ------- dump of incoming inband packet ------- interface Vl55, routine draco2_process_rx_packet_inline dbus info: src_vlan 0x37(55), src_indx 0x9(9), len 0x62(98)   bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896)   60020400 00370000 00090000 62000000 00110030 8E0FF7FC 00000000 03800000 mistral hdr: req_token 0x0(0), src_index 0x9(9), rx_offset 0x76(118)   requeue 0, obl_pkt 0, vlan 0x37(55) destmac 00.1D.E6.18.78.00, srcmac 00.22.A1.10.47.55, protocol 0800 protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 80, identifier 8754   df 0, mf 0, fo 0, ttl 124, src 195.94.31.92, dst 84.235.58.20     udp src 56349, dst 31777 len 60 checksum 0x0 L2 === Source mac 0022.A110.4755   2358 Dest mac     001D.E618.7800  4096 Protocol     0800    4096 Interface    Vl55     2358 Source vlan  0x37(55)   2358 Source index  0x2E(46)  1549 Dest index   0x380(896)   2367 L3 == ipv4 source   195.94.31.92   1498 ipv4 dest       195.94.31.106   996 Action plan: ========== ++ From Mac finder this mac address 0022.A110.4755 is of Huawei device . ++ Above  are the top Talkers,Looks like source mac  0022.A110.4755  is Huawei device ,learned on vlan 55 . ++ Trace the mac address  and look for the interface it is connected to and shut the interface,. ++ Need to check why this is sending so many packets? ++ Once you shut the source, check if cpu utilization is reduce. Regards, Naveen Venkateshaiah ... View more

Hi Mishal, When you say "remote login switch" you are actually checking switch processor CPU,and it looks good,13% is normal. I would request you to share below logs during the CPU is High debug netdr capture rx terminal lengh 0 show netdr capture Undebug netdr capture Or Undebug all Please share the logs in a text file and upload it ,i will analyze and update you on my findings. Regards, Naveen Venkateshaiah. ... View more

Hi Diburaj, Hulc LED Process covers a bunch of functions which including Link status monitoring, Management  interface handling etc and its consuming around 10-15% of CPU cycles can be expected on this platform. Basically the "Hulc LED" process does following tasks: - Check Link status on every port - If the switch supports POE, it checks to see if there is a Power Device (PD) detected - Check the status of the transceiver - Update Fan status - Set Main LED and ports LEDs - Update both Power Supplies and RPS - Check on system temperature status CPU utilization for Hulc LED Process of around 10-15% is seen on Cisco Catalyst 3750 and 3560 switches, even with no ports connected. show process cpu shows higher than expected CPU utilization.  This issue may be seen on a Catalyst 3750 or 3560 switch, typically with no ports connected.  I would suggest you that this is a minor issue and does not affect the hardware forwarding performance of the switch.  Below is the known Bug for your reference. https://tools.cisco.com/bugsearch/bug/CSCsi78581/?reffering_site=dumpcr Please do not hesitate to contact me in case you have any queries. Regards,   Naveen Venkateshaiah. ... View more

Hi Mishaal, From the logs i could see the high cpu due to interrupt.. sho processes cpu | exclude 0.0 CPU utilization for five seconds: 88% / 82% ; one minute: 91%; five minutes: 90%  You can capture the packet which are hitting the CPU, using 'netdr' tool. https://supportforums.cisco.com/document/59956/troubleshooting-netdr-capture-sup7206500  You can trace the source IP/MAC and try to shut that port and see if issue gets resolved Here is the procedure to capture, Netdr. debug netdr capture rx   terminal lengh 0   show netdr capture   Undebug netdr capture   Or   Undebug all Regards,   Naveen Venkateshaiah. ... View more