It appears that a switch is sending the same traffic to all ports in a VLAN:

  • In a Wireshark capture on host with MAC aaaa.aaaa.aaaa I see packets with MAC destination bbbb.bbbb.bbbb and Destination IP

ARP table on the switch contains a correct entry for, listing MAC of bbbb.bbbb.bbbb. The mac address-table entries, however, are missing bbbb.bbbb.bbbb.

After restarting the device, the MAC address table entry gets re-created.

EDIT: Whilst this 'flooding' (is this actually flooding?) is happening, the device continues to function well on the network! It is successfully transferring data. This is an important point: the device with MAC bbbb.bbbb.bbbb continues to send frames with source MAC bbbb.bbbb.bbbb to the switch. The switch is meant to save that MAC into its mac address table. But it doesn't!

What behaviour are we seeing here? Isn't the switch meant to flood the packets with destination MAC ffff.ffff.ffff, forcing the clients to read the packet contents to see if they are meant for them?

Also, I would greatly appreciate any advice on what other checks I can perform.

  • Does this answer your question? How does a switch learn a switch table?
    – Ron Trunk
    Apr 28 at 9:50
  • @RonTrunk, thank you for your comment. I have just come back from reading your very well-formulated answer to that question. But it apears that my situation breaks the premises described in your answer. Please see edit.
    – Tony Sepia
    Apr 28 at 10:06
  • Unfortunately, your question is simply too broad to answer as asked. Please edit the question to include things like the switch model and switch configuration.
    – Ron Maupin
    Apr 28 at 11:31
  • 1
    "flooding unknown unicast" is the full term, and appears to be what the switch is doing. As Zac answered, the switch should normally learn the location from sent traffic. However, if learning is disabled on that port, obviously it won't learn it. If the mac-address-table is full, it will have nowhere to record it. Check the switch configuration and logs. Also, check that the MAC isn't "malformed" with a broadcast/multicast bit set.
    – Ricky
    Apr 29 at 0:17
  • @Ricky, thank you for your recommendation! The first octet of the MAC is 00, so I guess the least significant bit is 0 (so all good on that front). I am in process of checking the rest of your recommendations, thank you!
    – Tony Sepia
    Apr 30 at 10:26

The mac address-table entries, however, are missing bbbb.bbbb.bbbb.

That is how a self-learning bridge works: it learns the location of nodes by the frames' source addresses and then forwards frames by the destination address based on the learned table.

If the node in question has never send a frame, the bridge/switch cannot know its location and subsequently floods frames with that destination out of all its ports, mimicking a repeater hub.

But in no case does a switch alter an unknown destination address in a frame to the broadcast address. (The only thing an L2 switch potentially changes in a frame is the 802.1Q tag.) The point is that the "unknown" MAC continues to function normally, even if the whole network is polluted with frames addressed for that node.

You should make sure that the node in question sends out a frame after link-up (or before it is eventually aged out), populating the switch's MAC address table (a link-down usually clears the addresses on that port). Some switches can also be configured for static MAC-port combinations, consult the manual.

  • Thank you, Zac. Please see my edit. Have I clarified why it is strange that the switch is failing to register the MAC?
    – Tony Sepia
    Apr 28 at 10:09
  • I appreciate your answer (vote up!), but the initial learning is not the problem. My question specified that after restarting the device bbbb.bbbb.bbbb the MAC address table is populated. The issue is that somehow the entry disappears from the table, while the device conitnues to send frames containing bbbb.bbbb.bbbb to the switch! Any troubleshooting tips that would isolate the problem would be very welcome! And if possible, please share your opinion: can it be called 'flooding' if the Dst MAC is not ffff.ffff.ffff?
    – Tony Sepia
    Apr 28 at 10:16
  • The devices don't see any problem with the switch failing to direct the frames properly - that's the whole point of flooding unknown MACs. MACs are removed from ports on link-down or by aging.
    – Zac67
    Apr 28 at 10:27
  • 1
    Yes, but possibly it doesn't receive frames for a long time.
    – Zac67
    Apr 28 at 10:37
  • 1
    Yes, pretty much (the received frame needs to use the MAC in question as source address). Another reason for removing a MAC from a port is when it's seen from another port - but that wouldn't cause flooding.
    – Zac67
    Apr 28 at 11:17

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