Re: Bridging with 2 unidirectional vlans and one phys if

Grant Taylor <[email protected]> Wed, 06 Feb 2008 10:35:15 -0600
Newsgroups gmane.linux.network.bridge.ebtables.user
Organization Riverview Technologies Inc.
Message-ID <[email protected]>
On 02/06/08 10:18, Zoilo Gomez wrote:
> It is 8139too (Realtek 8139).
> 
> But I do not think that it has anything to do with the network card 
> drivers. From inspecting tcpdump (monitoring on all interfaces) it is 
> obvious that the ARP Request goes out via vlan223 (correct), but the 
> Reply of course comes back on vlan200 (also correct) ... and from that 
> moment on, all IP-traffic is now bridged to vlan200 (instead of 
> vlan223), because that is where the MAC address replied ...

I too run 8139s and have no problems with them.  However there are some 
cards (that offload some functions from the driver to a CPU on the NIC?) 
that have these problems.

> So I tried to establish a static ARP entry:
> => arp -s 192.168.22.254 00:11:22:33:44:55 -i vlan223
> 
> The ARP entry shows up correctly in the arp table, but it seems to be 
> ignored: an ARP-request is sent out anyway for 192.168.22.254, in spite 
> of the static ARP-entry, and I end up in the same situation.
> 
> Anybody know why the static ARP-entry is ignored?

It is my (mis)understanding that the ARP cache is only used when the 
local system is trying to find the MAC address of an IP, not when it is 
forwarding frames.  Thus, if you are sending traffic from your host 
behind your Linux box the ARP cache on the Linux box will have no baring 
what so ever on where the traffic is sent.

> Anybody know how to force that all IP-traffic be sent via vlan223, 
> without ARP-interference?

I'm puzzled by the fact that the Linux bridge is behaving the way that 
it is.  I'm surprised that the traffic is not going out vlan223 like it 
is suppose to be.  This makes me believe there is something wrong with 
the bridging code to allow it to work in spite of EBTables.  Unless 
there is something like IPTables where traffic only passes EBTables on 
the first pass through the kernel (like IPTables NAT table).

On a whim, try adding the following EBTables rules and try again.

ebtables -A FORWARD -o eth1 -i vlan223 -j DROP
ebtables -A FORWARD -i eth1 -o vlan200 -j DROP

See what the counters say with these rules in place.

Also, make sure that you flush your EBTables in between tests to make 
sure that there is no stale rule that is effecting you.

Can we see the output of ebtables-save (I think that is correct)?



Grant. . . .

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/