Switch behavior when MAC table full

G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

A question for the experts:

If the MAC table of a switch is running full, will the switch then be
unable to learn new MAC addresses until some entries have timed out, or
will the switch just push old entries out of the MAC table to make room
for the new ones?

BR,
Kajfas
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

kajfas@hotmail.com wrote:
> A question for the experts:
>
> If the MAC table of a switch is running full, will the switch then be
> unable to learn new MAC addresses until some entries have timed out,
or
> will the switch just push old entries out of the MAC table to make
room
> for the new ones?

According to the IEEE 802.1D standard, when the MAC table is full,
the switch may (but does not have to) remove an existing entry
to make place for the new one. You'll probably find implementations
that handle this case in both of the ways that you mention.

Anoop
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1110554625.229528.311700@f14g2000cwb.googlegroups.com>,
"anoop" <ghanwani@gmail.com> wrote:

> kajfas@hotmail.com wrote:
> > If the MAC table of a switch is running full, will the switch then be
> > unable to learn new MAC addresses until some entries have timed out,
> or
> > will the switch just push old entries out of the MAC table to make
> room
> > for the new ones?
>
> According to the IEEE 802.1D standard, when the MAC table is full,
> the switch may (but does not have to) remove an existing entry
> to make place for the new one. You'll probably find implementations
> that handle this case in both of the ways that you mention.
>

Here's an excerpt from Chapter 2 of "The Switch Book" that discusses
this particular issue:

----begin excerpt----

The next obvious question is, ³If the table is full, what should I do
with new potential entries?² There are three possibilities:

(1) Learn the new address and discard an entry already in the table,
(2) Decrease the aging time to prune the table more rapidly, or
(3) Don¹t change anything, and ignore the new addresses until normal
aging makes entry space available.

All three solutions have their proponents. The problem with the first
approach is the difficulty in determining which existing entry should be
discarded. Conceivably, one might want to discard the entry that has not
had traffic sent to it for the longest time, using a least-recently-used
(LRU) algorithm. But this would require:

- A timestamp with a finer granularity than that used for the aging
timer.
In order to discard an entry sooner than the aging algorithm would,
we need a time measurement shorter than the aging time.

- A timestamp based on the use of the address as a destination, rather
than a source.

Remember that aging is based on how recently the entry was seen as a
sender of traffic, not as a receiver. If one wanted to prune the address
table earlier than dictated by normal aging, you would want to eliminate
those addresses that don¹t need to be looked up. This reflects its use
as a destination, not a source.

The added complexity is not easily justified.

The second approach assumes that the catenet can tolerate shorter aging.
The aging time should reflect the slowest rate of transmission by an
active station. That is, bridges assume that if a station has not been
heard from in an aging time, that it is really inactive or has moved. If
the aging timer can be reduced when the table is filled, why not reduce
it all the time and improve convergence time for moved stations? In
general, it is safer to have a longer-than-needed aging time than one
that is too short. If the aging time is set too short, the table can
³thrash². Stations that are really active (but with a transmission
frequency lower than the aging period) will be aged out prematurely and
must be constantly relearned. As the table design is generally optimized
for lookup (and not learning, which occurs less frequently), this
thrashing can be expensive in terms of bridge resources.

The third approach is both the easiest and most appropriate. If the
overload condition is transient, the aging process will soon make room
for the new entries. If the overload condition is sustained, this
indicates a configuration problem, which should be solved by a
reconfiguration rather than an algorithm modification. (You bought the
wrong bridge, buddy!)

----end excerpt----

© John Wiley & Sons and Networks & Communications Consulting.
All rights reserved.


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1110535977.296121.305230@o13g2000cwo.googlegroups.com>,
<kajfas@hotmail.com> wrote:
:If the MAC table of a switch is running full, will the switch then be
:unable to learn new MAC addresses until some entries have timed out, or
:will the switch just push old entries out of the MAC table to make room
:for the new ones?

It probably depends on the switch.

Leaving the old entries would be more robust in the face of
random-MAC attacks: if new junk MACs force out old then you are
going to have to flood all the real traffic -- but if you leave
the older MACs in place then as long as they have active traffic
you will have stable communications with those devices, and
you will age out the junk after the timeout.
--
Oh, to be a Blobel!
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

kajfas@hotmail.com wrote:

> A question for the experts:
>
> If the MAC table of a switch is running full, will the switch then be
> unable to learn new MAC addresses until some entries have timed out, or
> will the switch just push old entries out of the MAC table to make room
> for the new ones?
>
> BR,
> Kajfas
>
For most switches, the answer is neither. Most will simply bridge
everything to all ports when that happens (basically turning the switch
into a hub)
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

sean <sean@snerts-r-us.org> writes:

>kajfas@hotmail.com wrote:

>> If the MAC table of a switch is running full, will the switch then be
>> unable to learn new MAC addresses until some entries have timed out, or
>> will the switch just push old entries out of the MAC table to make room
>> for the new ones?
>>
>For most switches, the answer is neither. Most will simply bridge
>everything to all ports when that happens (basically turning the switch
>into a hub)

Are you saying that most switches will forget or ignore the current
contents of their MAC table, in that situation?

That would be about the most stupid thing to do, throwing away information
that was concidered fine milliseconds ago.

best regards
Patrick
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

Patrick Schaaf wrote:


>
> Are you saying that most switches will forget or ignore the current
> contents of their MAC table, in that situation?
>
> That would be about the most stupid thing to do, throwing away information
> that was concidered fine milliseconds ago.
>
> best regards
> Patrick
Yes, I am saying most switches will igonre the whole MAC table in that
case.

Don't know if it is TRULY "MOST" switches or not, as my experience is
limited to what I actually have.

Put it this way, tho - it's common enough that there used to be a
utility that flooded bogus mac addesses to switches to force this to
occur. It was intended by it's authors to allow one to run a protocol
analyzer (sniffer, ethereal, etc) and be able to sniff all ports on the
switch without needing to do port mirroring.
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

sean wrote:


> Yes, I am saying most switches will igonre the whole MAC table in that
> case.
>
> Don't know if it is TRULY "MOST" switches or not, as my experience is
> limited to what I actually have.
>
> Put it this way, tho - it's common enough that there used to be a
> utility that flooded bogus mac addesses to switches to force this to
> occur. It was intended by it's authors to allow one to run a protocol
> analyzer (sniffer, ethereal, etc) and be able to sniff all ports on the
> switch without needing to do port mirroring.
>
>

From: http://www.packetwatch.net/documents/papers/layer2sniffing.pdf

2.2 CAM Table Flooding
This attack uses MAC flooding to sniff traffic on the local area
network. Content Addressable
Memory (CAM) table flooding works by flooding the CAM table. CAM tables
store information like
MAC addresses, and switch ports, along with their VLAN information. CAM
tables have fixed sizes,
so they can only store a certain number of entries. The user wanting to
sniff the traffic floods the
switch with MAC addresses until the CAM table is full, at which point
the switch starts to broadcast
the traffic [4].
The attack starts by having the attacker flood the network with forged
gratuitous ARP packets that
each contains unique source MAC addresses. This causes some switches to
go into a hub-like mode
forwarding all traffic to all ports. What happens is that once the CAM
table is full, the traffic without
a CAM entry floods on the local VLAN. The already existing traffic with
existing entries in the CAM
table will not be forwarded out on all of the ports. Now, with the
traffic being broadcasted to
everyone, there will be no trouble sniffing it.
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1133moomlgacbea@news.supernews.com>,
sean <sean@snerts-r-us.org> wrote:

> sean wrote:
>
> > Yes, I am saying most switches will igonre the whole MAC table in that
> > case.
> >
>
> From: http://www.packetwatch.net/documents/papers/layer2sniffing.pdf
>
> 2.2 CAM Table Flooding
> This attack uses MAC flooding to sniff traffic on the local area
> network. Content Addressable
> Memory (CAM) table flooding works by flooding the CAM table. CAM tables
> store information like
> MAC addresses, and switch ports, along with their VLAN information. CAM
> tables have fixed sizes,
> so they can only store a certain number of entries. The user wanting to
> sniff the traffic floods the
> switch with MAC addresses until the CAM table is full, at which point
> the switch starts to broadcast
> the traffic [4].

I believe you may be misinterpreting the statement above. Once the
address table is full, the switch will flood all traffic *for
destinations that are not in the table* (i.e., the "new" stations that
cannot be stored), not that it will flood *all* traffic. Obviously, if
the table does not store some station addresses, those addresses (by
definition) are "unknown"; the proper behavior of a switch is to flood
frames destined for unknown addresses.


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

>
>
> I believe you may be misinterpreting the statement above. Once the
> address table is full, the switch will flood all traffic *for
> destinations that are not in the table* (i.e., the "new" stations that
> cannot be stored), not that it will flood *all* traffic. Obviously, if
> the table does not store some station addresses, those addresses (by
> definition) are "unknown"; the proper behavior of a switch is to flood
> frames destined for unknown addresses.

I don't think I am misinterpretting. Especially since the text uses the
phrase "hub mode". No qualifiers in the text that I can see about that
only being true for MAC addresses it has not learned before the table
filled up.

I know this is not how the switches SHOULD behave, but it seems that
many switches do indeed revert to being a hub when the MAC table fills
up. I have seen multiple discussions of this behavoir on the net - it's
a fairly well known phenomenon. In fact I am suprised that you of all
people have not heard of this.

It is also possible it's not a common problem but a common
misconception, of course. I'll search a little and post more links.
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

sean wrote:
> Rich Seifert wrote:
>
>>
>>
>> I believe you may be misinterpreting the statement above. Once the
>> address table is full, the switch will flood all traffic *for
>> destinations that are not in the table* (i.e., the "new" stations that
>> cannot be stored), not that it will flood *all* traffic. Obviously, if
>> the table does not store some station addresses, those addresses (by
>> definition) are "unknown"; the proper behavior of a switch is to flood
>> frames destined for unknown addresses.
>
>
> I don't think I am misinterpretting. Especially since the text uses the
> phrase "hub mode". No qualifiers in the text that I can see about that
> only being true for MAC addresses it has not learned before the table
> filled up.
>
> I know this is not how the switches SHOULD behave, but it seems that
> many switches do indeed revert to being a hub when the MAC table fills
> up. I have seen multiple discussions of this behavoir on the net - it's
> a fairly well known phenomenon. In fact I am suprised that you of all
> people have not heard of this.
>
> It is also possible it's not a common problem but a common
> misconception, of course. I'll search a little and post more links.
>

http://securityfocus.com/archive/105/294380/2002-10-04/2002-10-10/0
http://www.dshield.org/pipermail/unisog/2004-July/007375.html
http://www.cs.wright.edu/~pmateti/InternetSecurity/Lectures/Sniffers/
(for the above, look Under "capabilities of sniffers", item 3)

There are many more mentions of this on the net.
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

sean wrote:


> http://securityfocus.com/archive/105/294380/2002-10-04/2002-10-10/0
> http://www.dshield.org/pipermail/unisog/2004-July/007375.html
> http://www.cs.wright.edu/~pmateti/InternetSecurity/Lectures/Sniffers/
> (for the above, look Under "capabilities of sniffers", item 3)
>
> There are many more mentions of this on the net.
>
form: http://www.sans.org/resources/idfaq/switched_network.php
On some switches, it is possible to bombard the switch with bogus MAC
address data. The switch, not knowing how to handle the excess data,
will 'fail open'. That is, it will revert to a hub and will broadcast
all network frames to all ports. At this point, one of the more generic
network sniffers will work.
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1133v4facl9j6da@news.supernews.com>,
sean <sean@snerts-r-us.org> wrote:

>
> http://www.sans.org/resources/idfaq/switched_network.php
>
> which states:
> > MAC Flooding
> > Since switches are responsible for setting up the virtual circuits from
> > one node to another, they must keep a translation table that tracks
> > which addresses (specifically, which MAC addresses) are on which
> > physical port. The amount of memory for this translation table is
> > limited. This fact allows the switch to be exploited for sniffing
> > purposes. On some switches, it is possible to bombard the switch with
> > bogus MAC address data. The switch, not knowing how to handle the
> > excess data, will 'fail open'. That is, it will revert to a hub and
> > will broadcast all network frames to all ports. At this point, one of
> > the more generic network sniffers will work.
>
> Note is says it will broadcast *ALL* frames to *ALL* ports.
> And given whose website that's from, i would tend to trust it ;-)

And I would tend *not* to trust it, since the author thinks that
switches set up "virtual circuits from one node to another." Clearly,
the writer is "fast and loose" with his terminology, which leads me to
question what he means by "broadcast".

I have never heard of, nor seen, a switch that truly acts as a repeater
when its address table is full. In fact, since it would take
*additional, unneeded logic* in order to behave this way, I find it hard
to believe any designer would go to the trouble to do so.


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

> In article <1133v4facl9j6da@news.supernews.com>,
> sean <sean@snerts-r-us.org> wrote:
>
>
>>http://www.sans.org/resources/idfaq/switched_network.php
>>
>>which states:
>>
>>>MAC Flooding
>>>Since switches are responsible for setting up the virtual circuits from
>>
>> > one node to another, they must keep a translation table that tracks
>> > which addresses (specifically, which MAC addresses) are on which
>> > physical port. The amount of memory for this translation table is
>> > limited. This fact allows the switch to be exploited for sniffing
>> > purposes. On some switches, it is possible to bombard the switch with
>> > bogus MAC address data. The switch, not knowing how to handle the
>> > excess data, will 'fail open'. That is, it will revert to a hub and
>> > will broadcast all network frames to all ports. At this point, one of
>> > the more generic network sniffers will work.
>>
>>Note is says it will broadcast *ALL* frames to *ALL* ports.
>>And given whose website that's from, i would tend to trust it ;-)
>
>
> And I would tend *not* to trust it, since the author thinks that
> switches set up "virtual circuits from one node to another." Clearly,
> the writer is "fast and loose" with his terminology, which leads me to
> question what he means by "broadcast".
>
> I have never heard of, nor seen, a switch that truly acts as a repeater
> when its address table is full. In fact, since it would take
> *additional, unneeded logic* in order to behave this way, I find it hard
> to believe any designer would go to the trouble to do so.

Yes, I agree he is fast and loose with his terminology. But I have SEEN
this (seen switches start acting as hubs when the MAC address table
fills up)with my own eyes. Also, a large part of the functionality of
DSNIFF is based on this phenomenon.

Yes, it DOES require extra logic. I think the philosphy behind this
design is likely something along the lines of "it is better to lose the
swicth functionality and have uneccessary traffic go to ports where it
is not needed than drop any packets" - and of course this design will
wreak absolute havoc in a spanning tree environment - you'd basically
have it all start looping...
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <11347uu5chbd978@news.supernews.com>,
sean <sean@snerts-r-us.org> wrote:

>
> Yes, I agree he is fast and loose with his terminology. But I have SEEN
> this (seen switches start acting as hubs when the MAC address table
> fills up)with my own eyes.

How could you know that the frames that were being forwarded to all
ports contained destination addresses that were in the address table at
the instant they were forwarded? You would need continuous,
instantaneous visibility into the address table contents.

To understand what I mean, consider what happens if a designer chooses
"Option 1" from my Switch Book excerpt, i.e., when the table is full,
newly-learned source addresses would be stored, and existing entries
deleted from the table (using some unspecified algorithm to decide which
is to go). In the scenario you describe (i.e., a malicious device
intentionally sending rapid-fire frames with different, bogus source
addresses), the contents of the address table would be in constant flux.
It would be quite difficult to determine whether the destination address
in a flooded frame was actually in the address table at the time the
decision to flood was made. Addresses (both the bogus one and the real
ones) would be constantly stored and deleted from the table, making its
contents unpredictable on an instant-by-instant basis.

> Yes, it DOES require extra logic. I think the philosphy behind this
> design is likely something along the lines of "it is better to lose the
> swicth functionality and have uneccessary traffic go to ports where it
> is not needed than drop any packets"

But this is precisely what happens if the designer does *nothing*;
frames destined for stations whose addresses are currently in the table
receive proper switch behavior, and those who cannot be stored due to
table limitations are flooded. As you say, it is better to have the
unnecessary traffic go to ports where it is not needed than to drop
those packets; however, there is no need to revert to some sort of "hub
mode" to accomplish this.


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1134be9f59fp1a8@news.supernews.com>,
sean <sean@snerts-r-us.org> wrote:

> 1- try googling "fail open" "ethernet switch" -

I would argue that the normal, proper behavior could be described as
"fail open"; i.e., "open" for those addresses that could not be stored.
(As opposed to "fail closed", i.e., do not forward frames for unknown
destinations.) There is no clear definition of "fail open".


> 3- i've witnessed it

As I stated in an earlier post, how did you know?


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

sean <sean@snerts-r-us.org> writes:

>Patrick Schaaf wrote:

>> Are you saying that most switches will forget or ignore the current
>> contents of their MAC table, in that situation?
>>
>> That would be about the most stupid thing to do, throwing away information
>> that was concidered fine milliseconds ago.
>
>Yes, I am saying most switches will igonre the whole MAC table in that
>case.
>
>Don't know if it is TRULY "MOST" switches or not, as my experience is
>limited to what I actually have.

I'll leave it to others to comment on "most", because my experience
is practically limited to Cisco switches.

best regards
Patrick
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

Patrick Schaaf wrote:

> sean <sean@snerts-r-us.org> writes:
>
>
>>Patrick Schaaf wrote:
>
>
>>>Are you saying that most switches will forget or ignore the current
>>>contents of their MAC table, in that situation?
>>>
>>>That would be about the most stupid thing to do, throwing away information
>>>that was concidered fine milliseconds ago.
>>
>>Yes, I am saying most switches will igonre the whole MAC table in that
>>case.
>>
>>Don't know if it is TRULY "MOST" switches or not, as my experience is
>>limited to what I actually have.
>
>
> I'll leave it to others to comment on "most", because my experience
> is practically limited to Cisco switches.
>
> best regards
> Patrick

I have heard at least some of the catalysts do this.
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

> In article <1133v4facl9j6da@news.supernews.com>,
> sean <sean@snerts-r-us.org> wrote:
>
>
>>http://www.sans.org/resources/idfaq/switched_network.php
>>
>>which states:
>>
>>>MAC Flooding
>>>Since switches are responsible for setting up the virtual circuits from
>>
>> > one node to another, they must keep a translation table that tracks
>> > which addresses (specifically, which MAC addresses) are on which
>> > physical port. The amount of memory for this translation table is
>> > limited. This fact allows the switch to be exploited for sniffing
>> > purposes. On some switches, it is possible to bombard the switch with
>> > bogus MAC address data. The switch, not knowing how to handle the
>> > excess data, will 'fail open'. That is, it will revert to a hub and
>> > will broadcast all network frames to all ports. At this point, one of
>> > the more generic network sniffers will work.
>>
>>Note is says it will broadcast *ALL* frames to *ALL* ports.
>>And given whose website that's from, i would tend to trust it ;-)
>
>
> And I would tend *not* to trust it, since the author thinks that
> switches set up "virtual circuits from one node to another." Clearly,
> the writer is "fast and loose" with his terminology, which leads me to
> question what he means by "broadcast".
>
> I have never heard of, nor seen, a switch that truly acts as a repeater
> when its address table is full. In fact, since it would take
> *additional, unneeded logic* in order to behave this way, I find it hard
> to believe any designer would go to the trouble to do so.

Here is a link that specifically states Cisco Catalyst 5000's do this:

http://synfin.net/papers/switch_security.pdf
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

Well, enough talk, hopefully somebody can test it. Put one port in
promiscuous mode and another leave normal. Sniff both ports. Use one
of the programs that creates a mac flood to fill the table, then count
the packets on the two sniffers.

BTW, becoming a hub when the table fills is a good sales incentive for
a switch manufacturer to sell more memory on their switches, so why
should they not do it?
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

> In article <11347uu5chbd978@news.supernews.com>,
> sean <sean@snerts-r-us.org> wrote:
>
>
>>Yes, I agree he is fast and loose with his terminology. But I have SEEN
>>this (seen switches start acting as hubs when the MAC address table
>>fills up)with my own eyes.
>
>
> How could you know that the frames that were being forwarded to all
> ports contained destination addresses that were in the address table at
> the instant they were forwarded? You would need continuous,
> instantaneous visibility into the address table contents.
>
> To understand what I mean, consider what happens if a designer chooses
> "Option 1" from my Switch Book excerpt, i.e., when the table is full,
> newly-learned source addresses would be stored, and existing entries
> deleted from the table (using some unspecified algorithm to decide which
> is to go). In the scenario you describe (i.e., a malicious device
> intentionally sending rapid-fire frames with different, bogus source
> addresses), the contents of the address table would be in constant flux.
> It would be quite difficult to determine whether the destination address
> in a flooded frame was actually in the address table at the time the
> decision to flood was made. Addresses (both the bogus one and the real
> ones) would be constantly stored and deleted from the table, making its
> contents unpredictable on an instant-by-instant basis.
>

Yes. OK. I see now, you are dead right. That is likely exactly what is
going on. However, it appears to be a common misconception. Try
searching google for "macof" - there are dozens of sites that make the
same claim I did. Including the wiki pages for ethereal among others.

http://wiki.ethereal.com/CaptureSetup_2fEthernet
MAC Flooding: Swicthes keep a translation table that maps varios MAC
addresses to the physical ports on the switch. As a result of this it
can intelligently route packets from one host to another. The switch has
a limited memory for this work. MAC flooding makes use of this
limitation to bombard the switch with fake MAC addresses till the switch
can't keep up. The switch then enters into what is known as "failopen
mode" wherein it starts acting as a hub by broadcasting packets to all
the machines on the network. Once that happens sniffing can be performed
easily. MAC flooding can be performed by using macof, a utility that
comes with the dsniff suite



>
>>Yes, it DOES require extra logic. I think the philosphy behind this
>>design is likely something along the lines of "it is better to lose the
>>swicth functionality and have uneccessary traffic go to ports where it
>>is not needed than drop any packets"
>
>
> But this is precisely what happens if the designer does *nothing*;
> frames destined for stations whose addresses are currently in the table
> receive proper switch behavior, and those who cannot be stored due to
> table limitations are flooded. As you say, it is better to have the
> unnecessary traffic go to ports where it is not needed than to drop
> those packets; however, there is no need to revert to some sort of "hub
> mode" to accomplish this.
>

Yes again.

Thanks for teaching me.
 
Archived from groups: comp.dcom.lans.ethernet (More info?)

"It says that all frames
are dumped to all ports first (whatever that means)"

Many cisco switches,

5000 series (except 9 port GE card)
6000 series using Sup1, 1a (others?)

Not:-
8500, 4000, 4500, 1900, 2900, 3500

Others I don't know.

Use a shared bus architecture.

Every received frame is copied to the output
buffer of every port and to the supervisor.

The supervisor decides what to do with the frame
and then tells the various ports whether to drop or forward
the frame. The supervisor could in principle decide
for most frames what to do before larger frames were
fully received. I can't recall if that is what happens.

The ports get 'told' what to do by a bitmap with one
bit per port being sent from the Supervisor to the
line cards. This is quite efficient.


Advantages:-
Multicast, broadcast, and monitor (SPAN) ports
can be implemented with exactly zero performance
penalty.

Disadvantages:-
There are some but I can't recall for the moment:)