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