Re: Bridging with 2 unidirectional vlans and one phys if

Grant Taylor wrote:
> 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.
>   

Sorry: I am using VT6102 (Via Rhine-II) on eth0, ie. where the tagged 
VLANs vlan200 and vlan223 are.

But eth1 is 8139.

>> 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)?
>   

Thank you Grant; will be back later with the results.

Z.


-------------------------------------------------------------------------
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/