0

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

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

ARP table on the switch contains a correct entry for 192.168.0.20, 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 192.168.0.20 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.

Tony Sepia
  • 113
  • 6
  • Does this answer your question? [How does a switch learn a switch table?](https://networkengineering.stackexchange.com/questions/13012/how-does-a-switch-learn-a-switch-table) – Ron Trunk Apr 28 '21 at 09: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 '21 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 '21 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 '21 at 00: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 '21 at 10:26

1 Answers1

1

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.

Zac67
  • 81,287
  • 3
  • 67
  • 131
  • 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 '21 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 '21 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 '21 at 10:27
  • thank you. Do you agree that the switch should renew the MAC entry after receiving a frame with Source MAC bbbb.bbbb.bbbb? If Yes, then would you happen to have any advice on how to troubleshoot the problem? – Tony Sepia Apr 28 '21 at 10:35
  • 1
    Yes, but possibly it doesn't receive frames for a long time. – Zac67 Apr 28 '21 at 10:37
  • In other words, if I can prove that the switch receives a frame from the device with correct MAC, and that MAC isn't then found in the MAC address table, then it's a problem with the switch. Correct? – Tony Sepia Apr 28 '21 at 11:15
  • 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 '21 at 11:17