Re: Bridging with 2 unidirectional vlans and one phys if

Sorry to follow up on my own posting ... but I need to tell you how I =

fixed it.

As argued before, it seems that it cannot be done with a bridge really, =

because the bridge will learn the MAC-address on the receiving vlan =

interface, hence try to send all the traffic via the wrong (receiving) =

interface.

So I took my chances, and decided to try "bonding" to connect the 2 =

vlans. After putting the bonding interface in "broadcast" mode, it =

works! It can now ping from the PC to the SERVER via these VLANs.

Then I further connected the bond0-if and eth1 to a bridge (aux1) and =

... voil=E0: I got what I need:I can even ping from an external PC =

cross-connected to eth1:

Request traffic flows like: EXT_PC -> eth1 -> aux1 -> bond0 -> vlan223 =

-> SERVER
Reply traffic flows like: SERVER -> vlan200 -> bond0 -> aux1 -> EXT_PC

In summary:

vconfig eth0 vlan200
vconfig eth0 vlan223

ifenslave bond0 vlan200 vlan223

brctl addbr aux1
brctl addif aux1 bond0
brctl addif aux1 eth1

Not much to do with ebtables (I'm sorry) but I needed to report this result.

Thanks for all your support,

Z.

=3D=3D=3D=3D=3D

Zoilo Gomez wrote:
> 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:
>
>                   |------|=3D=3D=3D vlan223 (tx only) =3D=3D>|------|
> PC (tx + rx) =3D=3D=3D=3D>| aux1 |                         |switch|<=3D> =
SERVER
> 192.168.22.123/24 |------|<=3D=3D vlan200 (rx only) =3D=3D=3D|------|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:
> =3D> both Request and Reply on aux1 / PC
> =3D> only Request on vlan223
> =3D> only Reply on vlan200
> =3D> both Request and Reply at the SERVER
>
> =3D=3D=3D=3D=3D=3D
>
> Actually, now that I (think that I) am starting to understand it, it =

> makes perfect sense. Here is what I think is happening:
> =3D> the ping-request for 192.168.22.254 checks the router table and find=
s =

> aux1 as the target interface.
> =3D> an ARP-request is sent out via aux1
> =3D> the ARP-request is bridged to vlan223 (a copy sent to vlan200 is =

> dropped and shows up in dmesg)
> =3D> the ARP-request arrives at the SERVER, and is replied to
> =3D> the ARP-reply arrives at vlan200 and is bridged to aux1
>
> Great !  :-)
>
> =3D=3D=3D=3D=3D=3D
>
> 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 =3D> see d=
mesg.
>
> 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.
>
>
> =3D=3D=3D=3D
>
>
>
> Grant Taylor wrote:
>   =

>> On 02/06/08 10:18, Zoilo Gomez wrote:
>>   =

>>     =

>>> So I tried to establish a static ARP entry:
>>> =3D> 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/
> _______________________________________________
> 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/