04-12-2015 06:08 AM - edited 03-07-2019 11:30 PM
Hi,
Recently, I noticed some of my uplink ports of 3560 and 2960 are receiving lots of Broadcast. So far, the network is not degraded and the CPU's are not spiked. Here's a sample from my show interface command:
Received 6011451 broadcasts (4936113 multicasts). This is a 12 hours sample.
After using the debug command: debug platform cpu-queues broadcast-q, the log is filled with this message:
41w6d: L2B-Q:Dropped Duplicate Broadcast ARP/RARP: Local Port Fwding L3If:Vlan140 L2If:GigabitEthernet1/0/25 DI:0x61D, LT:1, Vlan:140 SrcGPN:25, SrcGID:25, ACLLogIdx:0x4, MacDA:ffff.ffff.ffff, MacSA: Removed MAC ARP: 00010800_06040001_E41F13C0_C9D60A8C_0A010000_00000000_0A8C0A19
TPFFD:E1410019_008C008C_01800040-0004061D_1E1E0000_00000000
The MAC source belongs to a Windows Server which is used to re-image workstation using multicast. I rebooted the server, but the errors keep
coming back. Does anybody ever seen this ? I'm thinking it might be a virus.
Thanks !
Solved! Go to Solution.
04-13-2015 09:59 PM
Hello Tony,
Where do you see the drops? Under sh controllers cpu-interface? Or sh platform port-asic stats drop?
I am quite not 100% sure on the internal architecture but my understanding is each cpu queue has its own buffers and it more important queue will have more buffers. For example we can assume that STP queue will have more buffers than Broadcast queue since dropping an STP packets can be more disruptive than dropping broadcasts. So these are internally tested and allocated buffers accordingly. So I hope if you see drops under broadcast queue it should not be a concern rather better measure to ensure switch does not drop more important packets.
Again on your queustion, I don't think there is a relation between ARP and multicast. I hope we will have more lights once server team performs an inspection of why it is sending lot of ARP.
Hope this helps
Thanks,
Madhu.
04-12-2015 09:07 AM
Hi again Tony,
Looks like you enabled debugging of cpu and finding the source of it and appreciate it.
How ever i think, you may need to further involve server team to have look at it to understand why it sending lot of broadcasts.
Hope this helps.
Regards,
Madhu,
04-13-2015 04:26 PM
Hi Madhu,
You guess it, I'm still working on the issue. Though, I'm getting closer to the solution. Tomorrow, I will have a talk with the server team. As I mentioned before, this server does multicast to re-image workstation, but the error specifically mentions ARP broadcast. Do you think there's a connection between ARP and multicast ? Also, why is it dropping packets ? There's no mention of dropped packets in the interface statistics.
Thanks !
Tony
04-13-2015 09:59 PM
Hello Tony,
Where do you see the drops? Under sh controllers cpu-interface? Or sh platform port-asic stats drop?
I am quite not 100% sure on the internal architecture but my understanding is each cpu queue has its own buffers and it more important queue will have more buffers. For example we can assume that STP queue will have more buffers than Broadcast queue since dropping an STP packets can be more disruptive than dropping broadcasts. So these are internally tested and allocated buffers accordingly. So I hope if you see drops under broadcast queue it should not be a concern rather better measure to ensure switch does not drop more important packets.
Again on your queustion, I don't think there is a relation between ARP and multicast. I hope we will have more lights once server team performs an inspection of why it is sending lot of ARP.
Hope this helps
Thanks,
Madhu.
04-14-2015 08:31 AM
Hi Madhu,
So far, no other logs is showing any drops. Including the 2 you mentioned on your previous post. The only log tha mention dropped packet is the command:
debug platform cpu-queues broadcast-q
Today at noon, we will shut the Windows server and see if the broadcast stop showing up.
I will keep you posted.
Tanks !
04-14-2015 10:03 AM
Hi Tony,
Thanks Keep us posted.
Regards,
Madhu
04-14-2015 01:25 PM
Hi Madhu, the window team found the spooler is still ARP'ing old printers which were removed. Also, the trace shows a laptop ARP'ing all IP's. This is probably a malware. It looks we're on the right track.
Thanks for your help !
Tony
04-16-2015 12:44 AM
Thanks Tony for the update.
Please consider rating any posts which were useful to you.
Also may be you consider closing it out as we possibly found the issue also.
Thanks,
Madhu.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide