Hello again : )
I really hope what you described above is not the case (unless of software defect).
I am sorry to disappoint you but what I described is a normal, logical, necessary part of any managed Ethernet switch operation. This transient flooding is both inevitable and measurable; it is trivial to reproduce on a switch using a custom frame generator and a packet sniffer.
Keep in mind: Upon receiving a frame with a new source MAC, the switch cannot wait till the ASIC or the operating system finished the programming of the MAC address table, possibly across many ASICs and across multiple linecards. It needs to get rid of the frame as soon as possible. So it does the best it can, given the current contents of the MAC address table, and performs the MAC learning in parallel to frame forwarding. And as I explained already, MAC address learning is orders of magnitude slower than forwarding lookups and frame forwarding, and hence the initial flooding is inevitable by the very principle. This is neither a bug, nor an imperfection - it is a rule given by the technical nature of the ASICs, and has always been around.
I would expect STP would prevent such "leak" by placing the port in blocking status
STP has nothing to do with flooding, neither with preventing it. STP builds a loop-free topology, nothing more. But even a loop-free topology must still perform flooding because that is what the proper delivery of BUM traffic (broadcast, unknown unicast, multicast) depends on.
Flooding is replicating exactly one copy of a received frame out every eligible outgoing port. On a single switch, flooding is not a chaotic, disorganized, endless process - on the contrary, it is very organized and controlled: A single incoming frame will be replicated and sent out exactly once through every proper outgoing port, and then the whole process for the given frame ends, period. As long as the switch does not receive the same frame again (which is where STP comes into play by eliminating loops from the topology where frames could flow around in circles), this flooding is a clearly delineated, delimited and finite process and has nothing to do with the dramatic network meltdown scenarios commonly associated with "flooding" and endless frame looping.
but I also understand that we are talking about a special frame/protocol and I find the behavior a bit unpredictable just by following logic and common sense.
Actually, I have strongly emphasized before, and I am strongly emphasizing again, that the LOOP frames are not special in any way. The only "weird" thing about them is that their source and destination MAC address is the same unicast MAC address. To any switch, Cisco or other vendor, they are first and foremost completely routine Ethernet frames in the Ethernet II (DIX) format and there is nothing extraordinary about their framing. Switches that don't support this specific protocol simply ignore the payload identified by the EtherType 0x9000, just like they ignore dozens if not hundreds of other unrecognized protocols encapsulated in Ethernet frames.
Don't treat these frames specially. There is nothing special about them. Their handling by switches, Cisco and others vendors, can be analyzed and derived by purely applying fundamental Ethernet switching rules. Anything more would be trying to invent fancy rules and exceptions where none exist nor are needed.
One of the hypothesis concerning my problem is that such LOOP frames are indeed forwarded through the looped L2 infrastructure (looped by design) and reach back the originating switch from another port (causing this 2nd port to be disabled).
This cannot be the case. A port on a Cisco Catalyst switch gets err-disabled only if it receives its own LOOP frame. If the port receives a LOOP frame originated by a different port, even of the same switch, nothing happens. This is trivial to demonstrate - simply connect two ports on the same Catalyst switch together and see what happens. STP will block one of the ports but that does not prevent any of them to continue sending and receiving LOOP frames because they're L2 control-plane traffic and that continues being processed even on ports in STP Blocking/Discarding state. There will be no err-disabling. Alternatively, if you want to be 100% certain, you can disable STP in the VLAN of the two ports; you still won't end up in either of the ports err-disabled.
Hence, if you see a port getting err-disabled because of detecting a looped condition, it must be because the port received its own LOOP frame it sent out at some point in the past. How that could have happened is the million dollar question here, but I can see only two possible explanations: Either you truly have a switching loop in progress, perhaps even a transient one, or the non-Cisco switches in your network violate the fundamental rule of Ethernet switching: Never forward a frame back through the interface it arrived on.
As always, feel welcome to ask / comment further!
Best regards,
Peter
