I am getting more than 60% of this traffic in my network.

Source Ethernet Address (6 bytes)                 00:00:00:00:00:00 (XEROX CORPORATION)
Destination Ethernet Address (6 bytes)            00:00:00:00:00:00 (XEROX CORPORATION)

Data (43 bytes)

What can I do to determine where this traffic is coming from?

How can I get rid of this traffic once the source is found?

  • How did verify this is happening? PCAP on a switch port? Was it monitor port or normal port? What does the data contain? If you have full PCAP it would be useful. – ytti Jun 10 '13 at 12:22
  • consider adding a mac acl that denies those adresses... – Mike Pennington Jun 10 '13 at 12:38
  • 2
    Something isn't right here and we would need more information. Please consider editing your question. – YLearn Jun 10 '13 at 13:29
  • What protocol is being encapsulated? IPv4? – Dennis Olvany Jun 11 '13 at 16:27
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 8 '17 at 9:51

This could be a misconfigured VM or multiple misonfigured VMs. That is where I saw the all zeroes originating before myself.

Getting rid of the traffic is easy. In an enterprise class switch, you should be able to add a static DROP entry to the MAC address table. This would cause the switch to drop this traffic at L2.

As for identifying the source, I wouldn't worry about that as they VMs probably are not functioning properly in any case. Blocking them should be sufficient, and the loss of all connectivity should point out the source (or create a support call) if it is legitimate.

| improve this answer | |
  • 1
    Blocking only hides the problems. A broken device is still spewing packets. If this is a misconfigured VM, it needs to be found and the path that led to it's creation FIXED. – Ricky Jun 10 '13 at 22:42
  • @RickyBeam, generally I would agree with this stance, but since most enterprise switches will drop this in hardware, there is no performance loss. I equate this to DHCP snooping in that it is just dropping the problematic traffic rather than letting it affect other devices on the network. If you have the time/ability to track it down later, absolutely you should do so (same with rogue DHCP), but it isn't a service impacting problem at that point and depending on the situation, it moves much further down the priority list. – YLearn Jun 11 '13 at 1:36
  • I wouldn't call 2960S's an enterprise switch, but it most certainly will NOT drop those; it won't put all-zero in the cam, thus has no dst for all-zero bam unicast flood. I hunt down and destroy VMs that do that, and then "have words" with the creator of said VM -- everyone in my office (all 8) know what they're doing to make those. (it's one of many stupid things our software can do) – Ricky Jun 11 '13 at 3:40
  • @RickyBeam, not sure where the 2960S switches come from, but they are definitely enterprise switches (CLI, SNMP, syslog, STP, detailed port stats, etc), unless you are only counting switches that can do L3. As for your assertion, I don't have access to a 2960S currently, but a 2950 (two gens back) will accept an all-zero drop statement and drop traffic, I can't imagine a 2960S wouldn't be able to do the same (although I wouldn't be overly surprised to find out it couldn't for some odd reason). – YLearn Jun 12 '13 at 0:53
  • can and will are different words. a switch can drop in hardware if configured to do so. The 2960S will not by default, nor will a 2950, btw. However, I totally agree src==dst should be dropped immediately; it's a rare enough event to not be coded into the hardware. – Ricky Jun 12 '13 at 1:45

If this traffic is indeed 60% of traffic, then I would start with looking at the interfaces for higher volume of input. I would then have a list of suspects. At that point I would mac acl a port at a time looking for when the traffic disappears. Then I know the source port of the traffic and then debug that 'thing'.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.