Re: [LARTC] What I learned about Linux bridging

[Grant Taylor <gtaylor@riverviewtech.net>]

On 6/6/2007 6:51 PM, Greg Scott wrote:
> Continuing with the above example, most of the write ups also say to 
> remove any IP Addresses from eth0, eth1, and eth2.  But I've found 
> this doesn't seem necessary - well, sort of.

No, you don't have to remove IP addresses from the bridge member 
interfaces, though it does make things (IMHO) cleaner and consistent.

You could put one IP address on each of the (physical) bridge member 
interfaces, or you could put the IP addresses (as aliases) on the bridge 
interface.

Although I'm not sure how well EBTables would be able to filter 
addresses on a raw interface verses on the bridge interface.

> Let's say that eth0 is at IP Address 1.2.3.2, and now I bridge eth0, 
> eth1, and eth2 together and give bridge br0 the same  IP Address of 
> 1.2.3.2.  Now I have a mess because both eth0 and br0 have the same 
> IP Address.  Doing this:

Yes, I would consider an IP address conflict a mess.

> But let's say that physical interface eth1 has IP Address 10.0.0.1. 
> From testing, it looks like other systems can ping 10.0.0.1 just 
> fine, assuming they have a route to it.  So I  **think**  I know that 
> I can assign an IP Address to a raw interface, as long as it's a 
> different IP Address than what I assigned to the overall bridge.  But 
> I haven't seen this capability documented anywhere.

Just because you can does not mean that you should.  Most people that 
are working (read:  using in production) bridging would not do so unless 
they had a need to do so.  If you do not need bridging, generally it is 
not used.  Thus if you can get by with putting the IP address(es) on the 
physical interfaces, then usually you will not be using bridging.  This 
does not mean that it can not be done.

> Let's say the bridge is up and working at IP Address 1.2.3.2.  I have 
> a system at IP Address 1.2.3.1 connected via eth0.  That system can 
> ping 1.2.3.2 easily.  If I disconnect the Ethernet cable from eth0 
> and plug into eth1 or eth2, after about 30 seconds, that bridged 
> system begins answering pings again.  As indicated in the write  ups, 
> that spare PC with a bunch of NICs is now acting like a managed
> Ethernet switch.  Cool!

In Spanning Tree Protocol, this is considered the listening / learning 
delay to prevent loops in the network.  This delay should be tunable 
(I'm not 100% certain of this fact).

> iptables is a super-sophisticated toolset to filter IP packets. 
> ebtables is another toolset to filter at the OSI layer 2 (datalink) 
> layer.  iptables concerns itself (mostly) with routing across an IP 
> network, computer to computer.  ebtables concerns itself (mostly) 
> with filtering packets across physical NIC interfaces in the same 
> computer.

Close, but not quite.

(I'll preface this paragraph by saying that by default, this is how 
IPTables behaves, as it can be changed.)

IPTables is a GREAT filtering framework that operates on OSI Layer 3 and 
higher (match extensions and what not).  EBTables is a VERY GOOD 
filtering framework that operates on OSI Layer 2.  I.e. one filters in 
the IP stack and the other filters in the bridging code (respectively). 
  Granted both IPTables and EBTables can filter on some things like 
source / destination IP address, IP protocol, TCP / UDP port, MAC 
address, and a few other things.  However IPTables has access to a LOT 
more information than EBTables does.

Now, for the non default config.  You can turn on "Bridge Netfilter" 
code in the kernel to allow the bridging code to use IPTables in 
addition to EBTables.  What this means is that you can use all of 
IPTables matches extensions to make OSI Layer 3 and higher decisions on 
OSI Layer 2.  I.e. you can have a bridging firewall do just about any 
thing that you want it to do.

> Here is a great writeup on using ebtables and iptables together: 
> http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html But - like 
> everything I've been able to find so far, I don't think this writeup 
> is completely accurate.

(It has been too long since I read that.  Please refresh my memory.) 
What about that write up do you think is in-accurate?  (I'll re-read the 
parts you point out.)  I'll see if I agree with you or the write up and 
if so try to help explain why.

> iptables has a module called physdev.  According to the writeup, I 
> can use the iptables physdev module to filter among the raw 
> interfaces in a bridge.  But a discussion in the netfilter list 
> essentially says that physdev is being removed because it creates all 
> kinds of other problems.  At least, I think that's what it says.  The 
> relevant discussion took place in early July 2006.  Here is a pointer 
> to the beginning of the discussion: 
> https://lists.netfilter.org/pipermail/netfilter-devel/2006-July/024896.html
> 
> So it looks like when filtering at the network layer, (IP in this 
> case) use iptables.  When filtering at the data link layer, use 
> ebtables and maybe arptables.  Avoid using -m physdev in iptables 
> because it's going away.  You can add IP Addresses to bridged eth-- 
> interfaces as long as they don't conflict with the bridge IP 
> Address(es).

With out reading too far in to it, it looks like the existing physdev 
match will be deprecated.  I however do not think this will be a 
permanent thing.  I believe that either a re-worked physdev, or 
something like it will re-appear in due time.

Also keep in mind that there is a LOT of re-working going on in the 
later 2.6.x kernels, including renaming variables and changing the 
internal workings.  (Too much so if you ask me for a .even release.)

> Next up will be to try some filtering scenarios with ebtables and 
> iptables.

...




Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc