Hmm.. I never saw this problem before. It _shouldn't_ bounce frames back. Can you just leave tcpdump running for a while on both interfaces just to be sure that no packets from 00:a0:24:cf:e8:8e come in via interface 2? I think STP was turned off by default because it was found to be 'insecure'. (Well, I mean, doh. If an attacker has physical access to the VLAN you run your STP instance in you're in for big trouble anyway.) On Thu, May 20, 2004 at 11:03:56PM +0200, Georg Schwarz wrote: > Hi, > > I'm trying to build a bridge using a 486DX2/66 with two 10 Mbit Ethernet > NICs. The machine (tsushima) is running Debian stable and kernel 2.4.26. > Previously I used it as a router, so I know the hardware (NICs) is > working. > The NICs are as follows: > eth0: WD80x3 at 0x280, 00 00 C0 0A 2C 2F WD8003-old, IRQ 10, shared > memory at 0xd0000-0xd1fff. > eth16i.c: v0.35 01-Jul-1999 Mika Kuoppala (miku@xxxxxx) > eth1: ICL EtherTeam 16i/32 at 0x240, IRQ 15, 00:00:4b:07:b3:9f TP > interface. > > eth0 is a BNC network, if that matters. > > I'm using the bridge-utils 0.95-2 from Debian stable, and I've set up > br0 with eth0 and eth1 via the interfaces script, as found in the > examples. There I've also assigned a static IP to br0 to access the > machine (bridge) from remote: > > tsushima:/etc/network# grep -v ^# interfaces > > auto lo > iface lo inet loopback > > auto br0 > iface br0 inet static > address 192.168.0.225 > network 192.168.0.0 > netmask 255.255.255.0 > broadcast 192.168.0.255 > gateway 192.168.0.1 > bridge_ports eth0 eth1 > > > > Now the problem is that the bridge appears to sometimes "reflect" frames > received on eth0 back to eth0. When I ping from one PC another PC on the > same side (eth0) of the bridge, i.e. in the same collision domain, I > often get duplicate replies when the bridge is running and connected > (and only then). This is not normal behaviour, is it? Is this a known > problem? > > I tried to nail down the problem. On the eth0 side there is a host > 192.168.0.1 and a host 192.168.0.39 (00:A0:24:CF:E8:8E). > On the bridge with brctl showmacs br0 I can see where 00:A0:24:CF:E8:8E > is supposed to be. It should be on port no. 1. Nevertheless, > brctl showmacs br0 sometimes shows the 00:a0:24:cf:e8:8e on port no. 2, > i.e. eth1. This is when the duplicates/reflections occur. > > At one instance: > > tsushima:/etc# brctl showmacs br0 > port no mac addr is local? ageing timer > 2 00:00:4b:07:b3:9f yes 0.00 > 2 00:00:c0:0a:26:69 no 10.52 > 1 00:00:c0:0a:2c:2f yes 0.00 > 2 00:10:a4:8d:b1:85 no 21.38 > 2 00:a0:24:cf:e8:8e no 0.37 > 1 08:00:07:d6:8e:f5 no 0.04 > 1 08:00:69:06:99:59 no 19.79 > > then after unplugging eth1 on the bridge and pinging from 192.168.0.1 to > 192.168.0.39: > > tsushima:/etc# brctl showmacs br0 > port no mac addr is local? ageing timer > 2 00:00:4b:07:b3:9f yes 0.00 > 1 00:00:c0:0a:26:69 no 36.85 > 1 00:00:c0:0a:2c:2f yes 0.00 > 2 00:10:a4:8d:b1:85 no 246.98 > 1 00:a0:24:cf:e8:8e no 44.13 > 1 08:00:07:d6:8e:f5 no 0.05 > 1 08:00:69:06:99:59 no 21.68 > > Here, 00:10:a4:8d:b1:85 really on the eth1 (port 2) side; all other > (non-local) MACs are not. > How can this happen??? > > > To get stop the phenomenon immediately, it turned out to be sufficient > unplug eth1 or to turn of the carrier on that interface. I've tried > several different machines connect to eth1 (via a TP cross cable). In > all cases the duplicates sooner or later did occur. > > The bride does not work; I cannot ping through it; strangely though dhcp > does work through it, as does arp resolution. > > My network is very simple. There's only that one bridge linking two > ethernet collission domains. > Unlike what /usr/share/doc/bridge-utils/README.Debian.gz says, STP seems > to be disabled by default. With the one-bridge network I have (no other > switches, really) this should not hurt though (and turning it on did not > make a difference). > In /etc/network/options both spoofprotect and ip_forwarding are set to > no (if that matters). > Could it be that ethernet broadcast frames are, under certain > conditions, reflected back to the incoming interface? > > > Any help on figuring out what's going wrong would be very much > appreciated. > > completely puzzled, Georg > > > -- > Georg Schwarz http://home.pages.de/~schwarz/ > geos@xxxxxxxx +49 177 8811442 >
