Re: Bridging with 2 unidirectional vlans and one phys if

In order to understand better what is exactly happening, I have decided 
to test first with the following simplified configuration, and see if 
can get this to work:

                  |------|=== vlan223 (tx only) ==>|------|
PC (tx + rx) ====>| aux1 |                         |switch|<=> SERVER
192.168.22.123/24 |------|<== vlan200 (rx only) ===|------|192.168.22.254/24


So instead of sending a packet from outside via eth1, I now send a 
ping-packet directly from the PC running the bridge itself.

The idea is that the aux1 bridge joins the tx- and rx-traffic back into 
a single interface.

Furthermore I made sure that vlan223 and vlan200 are not using 
IP-addresses, only aux1 does (192.168.22.123/24).

Finally, I set the following bridge rules (starting with clean ebtables 
configuration):

ebtables -P INPUT DROP
ebtables -P OUTPUT DROP
ebtables -P FORWARD DROP

ebtables -A OUTPUT --logical-out aux1 -o vlan223 -j ACCEPT
ebtables -A INPUT --logical-in aux1 -i vlan200 -j ACCEPT

ebtables -A INPUT --log-prefix "!INPUT"
ebtables -A OUTPUT --log-prefix "!OUTPUT"
ebtables -A FORWARD --log-prefix "!FORWARD"

No static ARP-rules this time.

And lo-and-behold! Now the ARP-traffic is working properly. Using 
tcpdump I can see:
=> both Request and Reply on aux1 / PC
=> only Request on vlan223
=> only Reply on vlan200
=> both Request and Reply at the SERVER

======

Actually, now that I (think that I) am starting to understand it, it 
makes perfect sense. Here is what I think is happening:
=> the ping-request for 192.168.22.254 checks the router table and finds 
aux1 as the target interface.
=> an ARP-request is sent out via aux1
=> the ARP-request is bridged to vlan223 (a copy sent to vlan200 is 
dropped and shows up in dmesg)
=> the ARP-request arrives at the SERVER, and is replied to
=> the ARP-reply arrives at vlan200 and is bridged to aux1

Great !  :-)

======

Only one tiny (new) problem left: as a result from the ARP-exchange 
above, the bridge has now learned that the SERVER MAC was last seen on 
vlan 200 ... and will try to bridge all IP-traffic (for example ICMP / 
ping) from aux1 to vlan200 (instead of vlan223), which is of course 
forbidden by ebtables and causes the ping-packet to be dropped => see dmesg.

So the ARP-problem is solved, but now I have a bridge MAC-learning 
problem instead ... which seems even harder to solve! :-(

I guess the new question is: "how can I force the bridge to send all the 
IP-traffic via vlan223, even though it is unidirectional, and no replies 
are ever being received on vlan223 ?

Thinking of the nature of bridges, I would think that this is in fact 
not possible ... perhaps I have to look for a different solution?

How can I tie a unidirectional UP-VLAN-interface and a unidirectional 
DOWN-VLAN-interface into one bidirectional interface?


To be continued ..... ;-)


Thanks so far for all the help!

Z.


====



Grant Taylor wrote:
> On 02/06/08 10:18, Zoilo Gomez wrote:
>   
>> 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?
>>     

I think I figured this part out: the static ARP-entry is not initially 
ignored, and used to send the first ICMP ping packet via vlan223. 
However, upon not receiving an icmp ping reply (because the reply 
arrives through vlan200), several ARP-requests are being sent out anyway.

>
> 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/
> _______________________________________________
> Ebtables-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
>
>   


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