Re: Dual-Homed/Triple-Subnet Bridge Challenge

I'm not actually back on site until this evening (Ireland/GMT).
Given the time difference, perhaps we can progress the discussion
a little further before then...

> > # ifconfig eth0 0.0.0.0
> > # ifconfig eth1 0.0.0.0
> > # brctl addbr bri0
> > # brctl addif bri0 eth0
> > # brctl addif bri0 eth1
> > # ifconfig bri0 up
> 
> You should not need to remove the addresses from the eth0 and eth1 
> interface.  You can easily have the addresses bound to them and use 
> bridging at the same time.

On my initial attempt, I followed your advice to the letter.
First I ensured that my home networks were working okay on each
interface,
the relevant /etc/network/interfaces excerpts being:

auto eth0
iface eth0 inet static
address 192.168.3.13
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
gateway 192.168.3.1
dns-nameservers 192.168.3.1

auto eth1
iface eth1 inet static
address 192.168.4.13
netmask 255.255.255.0
network 192.168.4.0
broadcast 192.168.4.255

I did a few ping tests to ensure home networks were okay.
Then I set up the bridge as follows:

# brctl addbr bri0
# brctl addif bri0 eth0
# brctl addif bri0 eth1
# ifconfig bri0 up

After issuing these commands, Zeroconf client ping tests failed
across the bridge and I could not ping on the home interfaces anymore.

But I'm now wondering did I wait long enough for the bridge to go
through its "learning" phase. You don't happen to know how long this
takes? Did I read 30 seconds somewhere? Is it dependent on interface
complexity?

Okay, in hindsight, I should probably try this again but, at the time,
I decided to scour Linux Bridging docs and I read somewhere that it was
necessary to unbind interfaces before bridging them by issuing the
following commands:

# ifconfig eth0 0.0.0.0
# ifconfig eth1 0.0.0.0

Now this may be a classic case of somebody making an assumption and
posting it as fact for newbies like me to latch onto...and it
wouldn't be the first time (I've probably done it myself).

In any case, this is a critical point we need to clear up from the
outset!

> > Next I set up slightly modified versions of your ebtables rules
> > specifying the ip4v protocol and ip-specific source/destination 
> > addresses. 
> > I assume you left these out for clarity.
> > 
> > # ebtables -t filter -A FORWARD -p IPv4 --ip-src 169.254.0.0/16 -j
> > ACCEPT
> > # ebtables -t filter -A FORWARD -p IPv4 --ip-dst 169.254.0.0/16 -j 
> > ACCEPT
> > # ebtables -t filter -A FORWARD -j DROP
> 
> I can't say why, but I'm not comfortable with these rules at 
> the moment. I feel like you should be doing something different,
> but I can't say what at the moment.

Your original rules did not work (I got an invalid source MAC
address error or something like that). Are my modifications above
at least correct in principle (whatever about the rules themselves)?

I'm wondering if the third rule above is causing 192.168.3.* and
192.168.4.*
packets to be dropped. A conceptual data path diagram would be nice here
i.e. where does the bridge filter actually reside in relation to the
*bound* eth0 and eth1 interfaces (as distinct from the *raw*
interfaces).
Would this depend on whether the interfaces were bound *before* or
*after*
the bridge was set up?

My guess is that the bridge filter would need to be first in line so
perhaps additional rules are necessary before the DROP rule to "route"
192.168.3.* and 192.168.4.* packets to the "internal" interfaces.
Maybe I'm clutching at straws here. Any ideas?

> Hum.  You should have been able to.  Do your EBTables rules show that 
> your third rule, "DROP" is matching frames?  Try flushing 
> your EBTables rules and see if things work.

I will try this first thing this evening.

> > The Dapper Universe version of EBtables I'm using is 2.0.6 
> (2003) which 
> > is quite old. Perhaps I will need to build from latest 
> source but I am 
> > a bit reluctant to do this in case it upsets anything else 
> in the stack.
> 
> I think you would be getting errors about the ebtables binary 
> not being 
> able to function with the kernel if there was a problem, but 
> I'm not sure.
> 

Would you consider EBtables 2.0.6 a reasonably solid version?
If not, is there a risk that I might de-stabilise my system if
I build EBtables from latest source? For example, would this
also require that I build the latest version of bridge-utils
from source?

Rgds,

Vincent


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