Switch behavior when MAC table full

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

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

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

In article , 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.

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)

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:

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.

I have heard at least some of the catalysts do this.

Has anyone seen a vendor create some type of security feature to prevent MAC table flood attacks? If so, I would be curious to know this works given that bogus MAC addresses could be completely random...

-mike

sean wrote:

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

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.

the above, look Under "capabilities of sniffers", item 3)

There are many more mentions of this on the net.

form:

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.

Um, how so? they basically repeat what I said! but a better link is:

which states:

Note is says it will broadcast *ALL* frames to *ALL* ports. And given whose website that's from, i would tend to trust it ;-)

That document only refers to catalyst 6000 series. Someone once told me thay had seen a cisco switch act as I desctribed. Sorry I do not have more details like model, who said it, what COS or IOS ver, etc.

I do know my Cisco 1548 at home behaves as I described, but you may not want to count that - (low end, discontinued, etc)

However, at no point did I ever say ALL switches. I did at one point say "most", and then I backpeddled on that.

I can say all I have tested this on (so far only netgear and low end cisco) do it.

I don't have the cajones to try it on my production baystack 450's yet. If it works it will disrupt things quite a bit. Maybe some quiet early morning, say at 3:00 am I might try it...

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.

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

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".

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

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