Multicast and flooding issue

[Daniel Senie]

As a follow-up to the message below, I have determined that the:

	options eepro100 multicast_filter_limit=3

also cures the problem I was seeing. I expect this "solves" the problem
by shifting the card into promiscuous during the tests I've been
running, and I already knew that promiscuous mode "solved" the problem I
was seeing.

It'd be nice to find an equivalent server motherboard with a Tulip chip
on it instead of the EEPro chip. Funny thing is, Intel owns both now.

Dan


Daniel Senie wrote:
> 
> I've read through the archives and see people discussing an issue I've
> seen, though my observance is just a little different. I'm working with
> some code for a client which does a lot of multicasting (it's a new OSPF
> implementation, I'm just testing it).
> 
> The target hardware I'm working with uses an Intel L440GX motherboard,
> which has an Intel 82555 chip on the motherboard.
> 
> When I start the application I'm testing, it starts sending out
> multicast frames, and quickly I get a lot of really odd results. These
> include:
> 
> - Getting the same multicast packet out onto the wire huge numbers of
> times.
> - Getting odd packets with all-zeros source and dest. MAC addresses, and
> some odd protocol type.
> 
> Two things seem to help:
> 
> - Killing the application, which turns off the multicast registrations.
> - Turning on promiscuous mode (either with ifconfig or by running
> tcpdump)
> 
> Also worth noting:
> 
> - most of the problem packets cannot be seen when looking from another
> port on a 10/100 switch. My test environment has the device under test,
> and a few other systems on a shared-media hub, so that I can analyze all
> packets coming from the box.
> 
> Conclusion: It appears the Ethernet driver may get confused over
> half/full duplex or be disabling or altering its collision logic when
> these problems are occurring. I do note that the ifconfig statistics
> show huge numbers for the received packets and collisions counters,
> though a low number for the transmit packets.
> 
> Dan
> 
> --
> -----------------------------------------------------------------
> Daniel Senie                                        dts@senie.com
> Amaranth Networks Inc.            http://www.amaranthnetworks.com


-- 
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.            http://www.amaranthnetworks.com