Hello,
Lots of ideas in your post Let's go over them one by one.
Which is largely the reason for the creation of bridging loops -
broadcast traffic originated by the end-user machines that gets
endlessly forwarded by Ethernet switches (like ARP), or is it the
broadcasting of unknown unicasts originated by the switches themselves?
Any frame that is delivered by flooding can create a storm. Such frames are broadcast frames, multicast frames and unicast frames whose destination is unknown. Note that these frames do not have to be originated by switches. They may well be originated by any connected station. As to the question what is the most commonly seen frame in such unicast/multicast/broadcast storms - I cannot say. Every network having redundant L2 links already runs STP or is already beaten to death by the storm I think that the type of frame causing a storm does not make any substantial difference - because the storms are not prevented by avoiding such frames but primarily by eliminating the L2 loops altogether. You cannot blame a particular frame type for creating problems in your network - a loop is a problem of the Layer2 switching topology, it is not created or prevented by limiting yourself to only a subset of all possible frames that can be transported over a switched network.
I would think its the broadcast traffic originated by the end-users
because unknown unicasts will eventually reach the intended machine and
the response packet will educate the switches that were reflexively
broadcasting earlier, thereby killing the loop. The caveat of course is
that the intended machine respond. If not, the broadcast storm will go
on and on. On the other hand, an ARP reply to an ARP broadcast (which is
a user generated broadcast) will still not break the loop.
Let's forget about STP for a while. You indeed seem to suppose that the loop is created and broken by the addressing information in MAC address tables. This would be more correct if we were speaking about L3 switching with IP routing tables. The logic in L2 is different, however, because it is a default and expected behavior that an unknown unicast/multicast/broadcast frame is forwarded out all ports except the ingress one. In essence, the default state of empty MAC address tables mandates that there will be a L2 loop if there are L1 loops. To put it plainly, with redundant links, the loop is there and it will still be there - just no frames may be currently caught in the loop. We do not identify a loop and its existence by the frames already circling in rounds but rather whether there is a possibility of a frame to circle indefinitely. In loop-free networks, there is no way how a frame could make a full round.
The elimination of L2 loops is therefore done not by eliminating traffic that can be caught in a loop but rather by eliminating the L2 loops themselves. This is obviously done by the family of STP protocols.
Perhaps you are asking about plain switches without STP support - well, in that case, things are unpleasant. A storm of frames destined to multicast or broadcast destination will go forever because no multicast or broadcast MAC address can be learned on a port (there is no station with its own source MAC address of broadcast or multicast). A storm of frames to an unknown unicast will be broken if that unknown destination replies and the reply goes back through at least one (ideally all) switches involved in the loop. There are situations when this would not be the case - think of asymmetrical routing where the route from A to B is different than the return path from B to A.
MY RATIONALE: There is a difference in that unknown unicasts are
broadcast (sent out) all ports (except the one in which it came in on)
but the destination MAC address is a unicast address and is not
changed. It is the forwarding behavior of the switches that changes when
unknown unicasts must be forwarded. On the other hand, broadcast
frames from end-users, like ARP queries, have a destination MAC address
that is itself a broadcast address (ffff.ffff.ffff), so even an ARP
reply will not kill the loop. Correct?
Yes, you are correct in the sense that if a frames already became engaged in a forwarding loop, this looping (but not the existence of the L2 loop alone!) can be stopped only for the unknown unicast frames when the unknown-so-far destination responds because that will stop the switches from flooding the frame. Broadcast and multicast frames caught in a loop cannot be stopped this way because their destination mandates they are flooded, and so they are.
But either way, can one say that it is the inherent nature of Ethernet
itself as a LAN broadcast protocol, which assumes a flat logical
topology, that is the underlying cause?
Correct. The Ethernet was from designed the beginning as a broadcast, with the physical layer being first a bus and then a star emulating the bus (hubs). Any looped configuration was considered as violation of the design rules for Ethernet network and the Ethernet alone does not have any safeguard mechanisms to detect and recover from such gross violations. L2 switches optimize the flows of traffic if that is possible but they still carry on the basics of Ethernet broadcast frame delivery, and thus they are also prone to L2 loops.
Best regards,
Peter
