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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
