Hi Jonathan, So, you're seeing the ARP reply come in, untagged, but not seeing it exit the tagged interface? Check to see that the bridge has definitely learned that MAC on the correct interface. I am wondering if your are coming up against this issue: --- (From http://ebtables.sourceforge.net/brnf-faq.html ) How do I let vlan-tagged traffic go through a vlan bridge port and the other traffic through a non-vlan bridge port? Suppose eth0 and eth0.15 are ports of br0. Without countermeasures all traffic, including traffic vlan-tagged with tag 15, entering the physical device eth0 will go through the bridge port eth0. To make the 15-tagged traffic go through the eth0.15 bridge port, use the following ebtables rule: ebtables -t broute -A BROUTING -i eth0 --vlan-id 15 -j DROP With the above rule, 15-tagged traffic will enter the bridge on the physical device eth0, will then be brouted and enter the bridge port eth0.15, the vlan header will be stripped, after which the packet is bridged. The packet thus enters the BROUTING chain twice, the first time with input device eth0 and the second time with input device eth0.15. The other chains are only traversed once. All other traffic will be bridged with input device eth0. ---- Somewhere I have seen a mailing list archive with a far better explanation, but I just can't seem to find it right now. Can you run TCPdump on 'in', as well as 'in.2' and see if the packets are disappearing somewhere between the two? Alternatively, put an ebtables rule on each interface, with a target of CONTINUE, and then do a ebtables -L --Lc to see which rules are matching, so you can get an ide of which interface the bridge is trying to spit out the replies you are looking for. Leigh. -----Original Message----- From: bridge-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx [mailto:bridge-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Thibault Sent: Wednesday, 12 March 2008 2:44 AM To: bridge@xxxxxxxxxxxxxx Subject: Re: bridge, vlan and *no* stp/bpdu Hello Leigh, This was one of the first things I looked at when I noticed that it didn't reach the client. As far as I can tell, no, the mac isn't on the wrong port. Come to think of it, I think the problem might have to do with the bridge not learning the affected machine's MAC at all until I removed in.3 from the bridge completely. I'll do further tests and confirm this shortly, especially if you think there is something to it. Also of note, since I monitor the trunk itself (and I only filter by mac when I do), I would have seen the reply if it went to the wrong vlan anyway, or is that logic wrong? Anyway, if the problem is that the bridge stops learning a specific machine's MAC, is there a way for me to manually add the MAC to the bridge table and see if it solves the problem? If such is the case, it's not really a solution, but it would certainly narrow down the scope of the problem. Jonathan Leigh Sharpe wrote: > Can you do a brctl showmacs br0, and see if the machines which are not > receiving an ARP response are being seen by the bridge as being on the > wrong VLAN? > > > Ie, I'm wondering if the bridge sees their MAC address on an interface > other than the one they are really connected to. If that's the case, the > bridge would send their response out of the wrong interface, which may > result in the symptoms you are describing. I think there may be some > ebtables rules which could help here, but my memory fails me at this > point. > > Regards, > Leigh > > Leigh Sharpe > Network Systems Engineer > Pacific Wireless > Ph +61 3 9584 8966 > Mob 0408 009 502 > Helpdesk 1300 300 616 > email lsharpe@xxxxxxxxxxxxxxxxxxxxxx > web www.pacificwireless.com.au > > _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
