|
Posted by on March 11, 2005, 2:12 am
If you were Registered and logged in, you could reply and use other advanced thread options
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
|
|
Posted by anoop on March 11, 2005, 7:23 am
If you were Registered and logged in, you could reply and use other advanced thread options
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
|
|
Posted by Rich Seifert on March 11, 2005, 8:22 am
If you were Registered and logged in, you could reply and use other advanced thread options
> 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
|
|
Posted by Walter Roberson on March 11, 2005, 11:07 am
If you were Registered and logged in, you could reply and use other advanced thread options
: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!
|
|
Posted by sean on March 11, 2005, 12:03 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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)
|
| Similar Threads | Posted | | 10M full forced port connected to 100M full Duplex port | March 25, 2006, 1:49 am |
| Full Duplex and Hub | April 13, 2006, 5:53 pm |
| hub in full duplex | May 26, 2006, 4:45 am |
| collisions on a 100% full duplex | May 18, 2006, 5:34 am |
| 100 mb Full duplex on fiber connection | August 2, 2005, 12:12 pm |
| A GbE device not able to forward full-rate odd-byte frames | November 2, 2005, 9:47 pm |
| how switches work - collision-free / full-duplex | March 23, 2007, 9:33 am |
| FPGA based Ethernet network analyzer - full wire speed, programmable | February 10, 2006, 9:38 pm |
| 10 to Auto/Auto or 100 Full on Cisco swich cost advantage | March 20, 2007, 9:11 am |
| 0000.0000.0000 MAC Addresses in ARP Table. | June 6, 2005, 6:04 am |
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map