Re: Dual-Homed/Triple-Subnet Bridge Challenge

On 02/12/08 07:09, Vincent Callanan wrote:
> Many thanks for your prompt and detailed response. Let me step back and
> give you some background before I answer your questions....

You are welcome.

<snip>

Thank you for the helpful and informative explanation of what you are 
wanting and what you have tried to do.

> Because of routing conflict (as discussed above)

I was thinking bind the 169.254.0.0/16 network to eth1 only, not eth0 
and eth1.  You are correct that binding to both will cause a routing 
problem if you can get it to bind at all.

> Sorry, I should have just said bridge from eth0 to eth1 (not eth0:0 to
> eth1)

No problem.

> eth1 will interface to both 169.254.*.* and 192.168.4.*
> eth0 will interface to both 169.254.*.* and 192.168.3.*
> 
> That's THREE subnets in total on TWO interfaces
> with no routing between these subnets
> but I do need to bridge between eth0 and eth1 for 169.254.*.* traffic
> only

*nod*

This is a perfect case for bridging.

> That looks good and makes sense even to me :)
> You say that my services will be bound to eth0 and eth1.
> Does that mean all three subnets will be visible?

Well, you have the option to have services bound to all subnets.  If 
they are bound, yes they will be visible.

> That's fine - I have no need for IP filtering (or forwarding) anyway.

Ok.

> I will want ARP broadcasts on 169.254.*.* to permeate both interfaces
> so that Zeroconf clients on either interface can detect conflicts during
> address negotiation. But I don't want ARPs from other subnets getting
> bridged.

This is not a problem.

> Do I need extra ebtables commands to ensure this?

No.

Based on what you are wanting to do, bind your 192.168.3/24 and 
192.168.4/24 subnets to eth0 and eth1 respectively.  Then bridge eth0 
and eth1 together in bri0.  (I like to name my bridges "bri" rather than 
"br", but what ever will work.)  Then bind 169.254/16 to bri0.  Set up 
ebtables rules that will cause any traffic entering the bridge not from 
and to the 169.254/16 network to be routed.  In EBTables terms this 
means to DROP (the packet out of the bridge and pass it on up to the 
routing code) the frame in the BROUTING chin of the broute table.

I believe this will have your desired result.  192.168.3/24, 
192.168.4/24, and 169.254/16 networks will all appear on their own 
interface where you can choose to bind (or not) your services to them. 
You should have little fear of traffic crossing the bridge that should 
not.  In fact, the only thing that may cross the bridge is ARP traffic 
(that does not need to), however you can even set up EBTables rules to 
stop that.

> My very basic understanding about Linux bridging is that each NIC is
> placed
> in promiscuous mode and the switches will also pass traffic which would
> not otherwise be visible on the Image Server ports. In other words,
> all traffic on each subnet is visible to the server and needs to be
> processed (and ignored where applicable).

Note quite.

The interface(s) are indeed put in to promiscuous mode.  However 
switches connected to the system do not do any thing different (save for 
Spanning Tree if it is used).  The promiscuous mode is just so that all 
frames that enter the interface can be passed to the bridging code, 
which will act like a software switch and decide what needs to be done 
with the frame.

> So let's say there is a heavy NFS backup happening on the 192.168.3.*
> subnet
> between two other servers. Will this traffic create a lot of unnecessary
> processing overhead for my Image Server?

No, that will not be a problem as long as you are on a modern (switched) 
network.

Remember that a switch will learn where a MAC address is at.  Thus if 
you have one (or more) MAC address(es) talking to one (or more) other 
MAC address(es), the switch will learn where source and destination MACs 
are in the conversation.  Once the switch has learned where (which 
port(s)) the destination MAC(s) is connected to, it will no longer send 
the frames out the other ports in the switch.  Thus if you are connected 
to a network with an NFS server and client (or what ever protocol) they 
will communicate directly with each other with out the switch sending 
the traffic to your system.

> Many thanks again for your help

You are welcome.



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/