cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4637
Views
0
Helpful
7
Replies

Excessive Broadcast

tonyp8581
Level 1
Level 1

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 !

 

 

 

1 Accepted Solution

Accepted Solutions

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.

 

 

 

View solution in original post

7 Replies 7

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,

 

 

 

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

 

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.

 

 

 

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 !

 

 

 

Hi Tony,

Thanks Keep us posted.

 

Regards,

Madhu

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

 

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.

 

 

Review Cisco Networking for a $25 gift card