Re: Dual-Homed/Triple-Subnet Bridge Challenge

On 02/14/08 07:46, Vincent Callanan wrote:
> I've finally got back on site to test your configuration settings. 
> I'm not quite there yet, so maybe you can get me over the last hurdle.

I'll try.

> # 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.

> After issuing these commands, I waited about a minute 
> to allow the server to settle into it's new role in life.
>  
> At this point, two Zeroconf clients connected on each interface 
> were able to ping each other. So far so good...

*nod*  This is as I would expect.

> Next I bound the bridge interface to it's own Zeroconf address
> 
> # ifconfig bri0 169.254.0.13 netmask 255.255.0.0
> 
> The two Zeroconf clients were still able to ping each other 
> and also ping the server. The server was also able to ping each 
> Zeroconf client. So far so good...

*nod*

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

> At this point, the two Zeroconf clients were still able to ping each 
> other 
> and also ping the server. The server was still able to ping each client. 
> So far so good...
> 
> Next I attempted to bind eth0 and eth1 to their home networks
> 
> # ifconfig eth0 192.168.3.13 netmask 255.255.255.0
> # ifconfig eth1 192.168.4.13 netmask 255.255.255.0

*nod*

> And this is where the "happy ever after" ending did not happen! 
> I was unable to ping any hosts on 192.168.3.* or 192.168.4.* 
> or ping the Image Server from these hosts.
> 
> Any suggestions would be welcome?

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.

> BTW, I have had good reason in the past not to trust software from the 
> Dapper *universe* repository, particularly low level stuff like 
> EBtables. 
> 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.



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/