Hi!
Noticed something strange today when I connected a RB450Gx4 (7.11.2) to another switch on a port where a device with a specific IP had previously been connected. Out of curiosity I ran a packet sniffer and saw another device send packets to this IP (which is no longer connected since I connected the RB instead). I think I see these packets arriving on the RB since the upstream switch still caches the previous devices MAC address for this port. Nothing strange with that except that I would I would have guessed the MAC maybe should have expired from the cache now several hours later…
But now comes the strangest thing, the RB then broadcasts this (non broadcast type packet) out on all of its ports belonging to the same bridge like if it doesn’t know what to do with it tries everything it can to try to find if it may be connected to any of its ports despite the bridge host table shows no trace of this MAC.
Is this broadcast like behaviour normal for a switch/bridge if it receives packets with unknown MACs? It was something completely new to me a switch/bridge could do this so I got a bit surprised…
Yes, this is normal behavior.
The first (unclear) description probably points to the fact that in RouterOS v7 the ARP table is not expired.
So the router remembers indefinately (until reboot) what the MAC address was for a certain IP address.
Then, when this MAC is not present in the bridge hosts table at a moment a directed packet is sent to that address, it is normal behavior to send it to all ports.
You can clear the ARP table using:
/ip arp remove [ find ]
(assuming you have not made any manual ARP entries and are not using “Add ARP for leases” in your DHCP server config)
Ah, maybe I should have mentioned, the upstream switch is not an mikrotik at all 
But I get the point that this is what is supposed to happen when a switch tries to populate it’s bridge host table. I thought this what done by just passively listening. So a switch is basically a hub then until it learns where a host lives 
If a switch receives a frame on a port it (passively) learns the source MAC address and caches it. However, if it needs to send to an unknown destination MAC address then it unicast forwards on all ports (https://en.wikipedia.org/wiki/Unicast_flood).
Yes it is required to work this way because some devices simply send no traffic at all for extended times, but still may need to be reached.
E.g. when you have a network printer or other passively monitored device like a UPS, it will initially do DHCP but for the entire time of the lease it may send nothing at all until someone wants to talk to it.
So this flooding is standard, not only for MilroTik but also for other switches.
What isn’t that common is that the ARP table in a router infinitely remembers entries. Usually they expire after a short while, e.g. 15 minutes, and a new ARP request/reply is required to reconfirm them.
That has changed in RouterOS v7, and I do not really like it either. It apparently is done because in a network with lots of systems, maintaining the ARP table was using considerable CPU load. But maybe there should have been an option to select between the old and new version, as in many networks it would not be an issue at all due to the small number of entries or the sufficient CPU power of a CCR to handle it anyway.
Now we are left with the option of doing it manually, by putting the above command in a scheduled script that regularly drops the entire table (it will quickly be re-populated with the systems active at that moment).