Switch behavior when MAC table full

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
21 answers Last reply
More about switch behavior table full
  1. 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
  2. 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
  3. 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!
  4. 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)
  5. 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
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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...
  14. 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
  15. 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
  16. 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
  17. 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.
  18. 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
  19. 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?
  20. 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.
  21. 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:)
Ask a new question

Read More

Switch Ethernet Card Macintosh Networking