Bridges are devices which can be installed in a network without any
reconfiguration. A network switch is basically a many-port bridge. A bridge
is often a 2-port switch. Linux does however support multiple interfaces in
a bridge, making it a true switch.
Bridges are often deployed when confronted with a broken network that needs
to be fixed without any alterations. Because the bridge is a layer-2 device,
one layer below IP, routers and servers are not aware of its existence.
This means that you can transparently block or modify certain packets, or do
shaping.
Another good thing is that a bridge can often be replaced by a cross cable
or a hub, should it break down.
The bad news is that a bridge can cause great confusion unless it is very
well documented. It does not appear in traceroutes, but somehow packets
disappear or get changed from point A to point B. You should also wonder if
an organization that 'does not want to change anything' is doing the right
thing.
As of Linux 2.4.14, bridging and iptables do not 'see' each other without
help. If you bridge packets from eth0 to eth1, they do not 'pass' by
iptables. This means that you cannot do filtering, or NAT or mangling or
whatever.
There are several projects going on to fix this, the truly right one is by
the author of the Linux 2.4 bridging code, Lennert Buytenhek. He recently
informed us that as of bridge-nf 0.0.2 (see the url above), the code is
stable and usable in production environments. He is now asking the kernel
people if and how the patch can be merged, stay tuned!
This does work as advertised. Be sure to figure out which side each
interface is on, otherwise you might be shaping outbound traffic in your
internal interface, which won't work. Use tcpdump if needed.
If you just want to implement a Pseudo-bridge, skip down a few sections
to 'Implementing it', but it is wise to read a bit about how it works in
practice.
A Pseudo-bridge works a bit differently. By default, a bridge passes packets
unaltered from one interface to the other. It only looks at the hardware
address of packets to determine what goes where. This in turn means that you
can bridge traffic that Linux does not understand, as long as it has an
hardware address it does.
A 'Pseudo-bridge' works differently and looks more like a hidden router than
a bridge, but like a bridge, it has little impact on network design.
An advantage of the fact that it is not a brige lies in the fact that
packets really pass through the kernel, and can be filtered, changed,
redirected or rerouted.
A real bridge can also be made to perform these feats, but it needs special
code, like the Ethernet Frame Diverter, or the above mentioned patch.
Another advantage of a pseudo-bridge is that it does not pass packets it
does not understand - thus cleaning your network of a lot of cruft. In cases
where you need this cruft (like SAP packets, or Netbeui), use a real bridge.
ARP & Proxy-ARP
When a host wants to talk to another host on the same physical network
segment, it sends out an Address Resolution Protocol packet, which, somewhat
simplified, reads like this 'who has 10.0.0.1, tell 10.0.0.7'. In response
to this, 10.0.0.1 replies with a short 'here' packet.
10.0.0.7 then sends packets to the hardware address mentioned in the 'here'
packet. It caches this hardware address for a relatively long time, and
after the cache expires, it reasks the question.
When building a Pseudo-bridge, we instruct the bridge to reply to these ARP
packets, which causes the hosts in the network to send its packets to the
bridge. The brige then processes these packets, and sends them to the
relevant interface.
So, in short, whenever a host on one side of the bridge asks for the
hardware address of a host on the other, the bridge replies with a packet
that says 'hand it to me'.
This way, all data traffic gets transmitted to the right place, and always
passes through the bridge.
Implementing it
In the bad old days, it used to be possible to instruct the Linux Kernel to
perform 'proxy-ARP' for just any subnet. So, to configure a pseudo-bridge,
you would have to specify both the proper routes to both sides of the bridge
AND create matching proxy-ARP rules. This is bad in that it requires a lot
of typing, but also because it easily allows you to make mistakes which make
your bridge respond to ARP queries for networks it does not know how to
route.
With Linux 2.4/2.5 (and possibly 2.2), this possibility has been withdrawn and
has been replaced by a flag in the /proc directory, called 'proxy_arp'. The
procedure for building a pseudo-bridge is then:
Assign an IP address to both interfaces, the 'left' and the 'right'
one
Create routes so your machine knows which hosts reside on the left,
and which on the right
Turn on proxy-ARP on both interfaces, echo 1 >
/proc/sys/net/ipv4/conf/ethL/proxy_arp, echo 1 >
/proc/sys/net/ipv4/conf/ethR/proxy_arp, where L and R stand for the numbers
of your interfaces on the left and on the right side
Also, do not forget to turn on the ip_forwarding flag! When converting from
a true bridge, you may find that this flag was turned off as it is not
needed when bridging.
Another thing you might note when converting is that you need to clear the
arp cache of computers in the network - the arp cache might contain old
pre-bridge hardware addresses which are no longer correct.
On a Cisco, this is done using the command 'clear arp-cache', under
Linux, use 'arp -d ip.address'. You can also wait for the cache to expire
manually, which can take rather long.
