| Author |
Message |
Arnold Nipper
Guest
|
 Posted:
Sat Mar 12, 2005 5:02 am Post subject:
Re: Switch behavior when MAC table full |
|
|
On 12.03.2005 00:37 sean wrote
| Quote: | Arnold Nipper 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.
agreed. However-
1- try googling "fail open" "ethernet switch" - dozens of links
decribing what I state. (and many dozens of links as well that have
nothing to do with the topic, so you do need to sort through a bit)
2- dsniff is in part based on this phenomenon being real.
3- i've witnessed it
|
I'm taking the easiest part and had a look at dnsiff
(http://www.monkey.org/~dugsong/dsniff/faq.html#How%20do%20I%20sniff%20in%20a%20switched%20environment)
and can't find any indication for your statement ...
Maybe it's just too late over here in good old Europe.
Gnight, Arnold
--
Arnold Nipper, AN45 |
|
| Back to top |
|
 |
Rich Seifert
Guest
|
| Posted:
Sat Mar 12, 2005 5:32 am Post subject:
Re: Switch behavior when MAC table full |
|
|
In article <11347uu5chbd978@news.supernews.com>,
sean <sean@snerts-r-us.org> wrote:
| Quote: |
Yes, I agree he is fast and loose with his terminology. But I have SEEN
this (seen switches start acting as hubs when the MAC address table
fills up)with my own eyes.
|
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.
| Quote: | Yes, it DOES require extra logic. I think the philosphy behind this
design is likely something along the lines of "it is better to lose the
swicth functionality and have uneccessary traffic go to ports where it
is not needed than drop any packets"
|
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 |
|
| Back to top |
|
|
Rich Seifert
Guest
|
| Posted:
Sat Mar 12, 2005 5:35 am Post subject:
Re: Switch behavior when MAC table full |
|
|
In article <1134be9f59fp1a8@news.supernews.com>,
sean <sean@snerts-r-us.org> wrote:
| Quote: | 1- try googling "fail open" "ethernet switch" -
|
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".
| Quote: | 3- i've witnessed it
|
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 |
|
| Back to top |
|
|
sean
Guest
|
| Posted:
Sat Mar 12, 2005 5:40 am Post subject:
Re: Switch behavior when MAC table full |
|
|
Rich Seifert wrote:
| Quote: | In article <11347uu5chbd978@news.supernews.com>,
sean <sean@snerts-r-us.org> wrote:
Yes, I agree he is fast and loose with his terminology. But I have SEEN
this (seen switches start acting as hubs when the MAC address table
fills up)with my own eyes.
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.
|
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.
http://wiki.ethereal.com/CaptureSetup_2fEthernet
MAC Flooding: Swicthes keep a translation table that maps varios MAC
addresses to the physical ports on the switch. As a result of this it
can intelligently route packets from one host to another. The switch has
a limited memory for this work. MAC flooding makes use of this
limitation to bombard the switch with fake MAC addresses till the switch
can't keep up. The switch then enters into what is known as "failopen
mode" wherein it starts acting as a hub by broadcasting packets to all
the machines on the network. Once that happens sniffing can be performed
easily. MAC flooding can be performed by using macof, a utility that
comes with the dsniff suite
| Quote: |
Yes, it DOES require extra logic. I think the philosphy behind this
design is likely something along the lines of "it is better to lose the
swicth functionality and have uneccessary traffic go to ports where it
is not needed than drop any packets"
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.
|
Yes again.
Thanks for teaching me. |
|
| Back to top |
|
|
sean
Guest
|
| Posted:
Sat Mar 12, 2005 5:45 am Post subject:
Re: Switch behavior when MAC table full |
|
|
Arnold Nipper wrote:
| Quote: | On 12.03.2005 00:37 sean wrote
Arnold Nipper 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.
agreed. However-
1- try googling "fail open" "ethernet switch" - dozens of links
decribing what I state. (and many dozens of links as well that have
nothing to do with the topic, so you do need to sort through a bit)
2- dsniff is in part based on this phenomenon being real.
3- i've witnessed it
I'm taking the easiest part and had a look at dnsiff
(http://www.monkey.org/~dugsong/dsniff/faq.html#How%20do%20I%20sniff%20in%20a%20switched%20environment)
and can't find any indication for your statement ...
Maybe it's just too late over here in good old Europe.
Gnight, Arnold
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. |
|
| Back to top |
|
|
sqrfolkdnc
Guest
|
| Posted:
Sat Mar 12, 2005 8:02 am Post subject:
Re: Switch behavior when MAC table full |
|
|
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? |
|
| Back to top |
|
|
Guest
|
| Posted:
Mon Mar 14, 2005 6:48 pm Post subject:
Re: Switch behavior when MAC table full |
|
|
"It says that all frames
are dumped to all ports first (whatever that means)"
Many cisco switches,
5000 series (except 9 port GE card)
6000 series using Sup1, 1a (others?)
Not:-
8500, 4000, 4500, 1900, 2900, 3500
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:) |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in