Switch behavior when MAC table full

Here is a link that specifically states Cisco Catalyst 5000's do this:

You are right. It says when the processor is overloaded, not when the cam table is full. so nix that example.

agreed. However-

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?

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.

Yes again.

Thanks for teaching me.

Try looking for "macoff"

However Mr. Siefert has corrected my misconceptions on this matter. (he getrs my vote for most valuable user of usenet hands down - this is not the first time he's taken the time to correct my misconcepotions)

It's likely that what I have seen is the switch gets flooded and throws away the older mac entries. Therefore things that USED to be in the cam are no longer there, so it LOOKS like it's acting as a hub, but it ain't. Since all the real mac addresses have been superceded by garbage, you DO see all traffic. But not beacuse it's really acting like a hub.

I suppose it will not broadcast to all ports whatever gets freshly arped while the flood is occuring (Until the MAC sent in the arp reply flushes out again), but it would look enough like all traffic is being broadcast to all ports that a casual observer will not see the difference.

On 11.03.2005 20:43 sean wrote

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

Repeating false does not make it true ;-)

Arnold

On 11.03.2005 20:33 sean wrote

At least Cisco switches behave as how Rich pointed out. See

Arnold

On 11.03.2005 21:07 sean wrote

Note also that ist says _On some switches_ ... that's quite different than _on all switches_

So I guess "all switches will flood some frames" and "some switches will flood all frames" is the truth ;-)

Arnold

On 11.03.2005 21:18 sean wrote

That documents says "This document is not restricted to specific software and hardware versions."

Arnold

On 11.03.2005 22:24 Michael Roberts wrote

CatOS lets you disable unicast-flooding on a per port basis.

sw003> (enable) set port unicast-flood 1/1 disable

See

Arnold

On 11.03.2005 23:37 sean wrote

What you write does not make sense to me. Only flooding traffic for unknown MAC addresses would already match your philosophy whereas traffic for known destinations is still not flooded.

Moreover imagine what flooding all traffic means on a switch with different port speeds. A lightly loaded GE port will swamp all FE and Eth ports already when there is minimal traffic for an unknown destination.

And as Rich pointed out: you need extra logic which buys you nothing.

Arnold

On 12.03.2005 00:05 sean wrote

Read carefully ... that paper doesn't say that. It says that all frames are dumped to all ports first (whatever that means) and that the Sup hats to tell each port beside the actual destination port to drop the frame.

I can't find any line that says that the Cat5k dumps traffic from all ports to all ports when the cam table is full.

Arnold

On 12.03.2005 00:37 sean wrote

I'm taking the easiest part and had a look at dnsiff

Maybe it's just too late over here in good old Europe.

Gnight, Arnold

"It says that all frames are dumped to all ports first (whatever that means)"

Many cisco switches,

Not:-

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:)