> On Apr 12, 2022, at 10:44 AM, Todd Goodman <t...@bonedaddy.net> wrote:
>
>
> On 4/12/2022 10:12 AM, Paul Koning wrote:
>>
>>> On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk
>>> <cctalk@classiccmp.org> wrote:
>>> ...
>>> The big difference in my mind between bridge and switch is:
>>>
>>> * Switches learn what port given MACs are on and only sends unicast
>>> traffic destined for that MAC address on that port and not all
>>> * Bridges send unicast traffic to all ports
>> Absolutely not. The only standard device that forwards unicast to all ports
>> is the repeater. I don't know of any packet forwarding device that sends
>> unicast traffic to all ports; certainly no such thing can be found in any
>> standard.
>>
>> Learning was introduced by DEC in the DECbridge 100 (along with spanning
>> tree); IEEE later standardized this, with some small mods, in 802.1d.
>>
>> paul
>
> You snipped the part where I said except for ports that should not receive
> the traffic due to blocked ports from the Spanning Tree Protocol in 802.1d
> and that if that fails you end up with a broadcast storm.
>
> Well, I didn't mention STP in 802.1d specifically because I thought it was
> obvious.
>
> Bridges were useful even after switches arrived to allow monitoring of
> traffic on any port of the bridge. It was useful before switches got port
> mirroring and even after as it didn't require any configuration.
Yes, I snipped part of what you said, but that doesn't affect my point.
Learning has always been part of what bridges do. It's a core part of the DEC
bridge spec, and a core part of the DECbridge-100 functionality. It is the
reason why Tony Lauck and George Varghese invented the "timer wheels" scheme
for keeping 8000 timers in constant time.
A device that doesn't do address learning and floods unicast frames is not a
bridge but rather a non-standard piece hardware. I don't actually know if
anyone ever implemented such a device. Certainly I've never seen one or built
one myself, even though what I built was called "bridge".
paul
