Switch behavior when MAC table full
DComTalk.com Forum Index DComTalk.com
Discussion of VoIP, VPN, Video Conferencen, DSL and other data commucations.
 
 FAQFAQ   MemberlistMemberlist     RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Google
 
Web dcomtalk.com
Switch behavior when MAC table full
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    DComTalk.com Forum Index -> Ethernet
Author Message
Guest






Posted: Fri Mar 11, 2005 3:12 pm    Post subject: Switch behavior when MAC table full Reply with quote

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
Back to top
Walter Roberson
Guest





Posted: Fri Mar 11, 2005 4:07 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

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!
Back to top
anoop
Guest





Posted: Fri Mar 11, 2005 8:23 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

kajfas@hotmail.com wrote:
Quote:
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
Back to top
Rich Seifert
Guest





Posted: Fri Mar 11, 2005 9:22 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

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

Quote:
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
Back to top
sean
Guest





Posted: Fri Mar 11, 2005 10:03 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

kajfas@hotmail.com wrote:

Quote:
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)
Back to top
Patrick Schaaf
Guest





Posted: Fri Mar 11, 2005 10:22 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

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

Quote:
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
Back to top
sean
Guest





Posted: Fri Mar 11, 2005 10:37 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

Patrick Schaaf wrote:


Quote:

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.
Back to top
sean
Guest





Posted: Fri Mar 11, 2005 10:44 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

sean wrote:


Quote:
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.
Back to top
Patrick Schaaf
Guest





Posted: Fri Mar 11, 2005 11:00 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

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

Quote:
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
Back to top
sean
Guest





Posted: Fri Mar 11, 2005 11:12 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

Patrick Schaaf wrote:

Quote:
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.
Back to top
Rich Seifert
Guest





Posted: Fri Mar 11, 2005 11:21 pm    Post subject: Re: Switch behavior when MAC table full Reply with quote

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

Quote:
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
Back to top
sean
Guest





Posted: Sat Mar 12, 2005 12:33 am    Post subject: Re: Switch behavior when MAC table full Reply with quote

Rich Seifert wrote:

Quote:


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.
Back to top
sean
Guest





Posted: Sat Mar 12, 2005 12:43 am    Post subject: Re: Switch behavior when MAC table full Reply with quote

sean wrote:
Quote:
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.
Back to top
sean
Guest





Posted: Sat Mar 12, 2005 12:47 am    Post subject: Re: Switch behavior when MAC table full Reply with quote

sean wrote:


Quote:
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.
Back to top
Arnold Nipper
Guest





Posted: Sat Mar 12, 2005 1:04 am    Post subject: Re: Switch behavior when MAC table full Reply with quote

On 11.03.2005 20:43 sean wrote

Quote:
sean wrote:
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)


neither of the above mentioned URLs really backs up your statement.

Quote:
There are many more mentions of this on the net.


Repeating false does not make it true ;-)



Arnold
--
Arnold Nipper, AN45
Back to top
 
Post new topic   Reply to topic    DComTalk.com Forum Index -> Ethernet All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




VoIP Solutions: Telephone Systems Electronics Satellite TV Tech & Gadgets
Powered by phpBB