It is sometimes useful to divide one physical network (such as an Ethernet segment) into two separate network segments without having to create IP subnets and use a router to connect the segments together. A device that connects two networks together in this fashion is called a ``bridge''. A FreeBSD system with two network interface cards can act as a bridge.
The bridge works by learning the MAC layer addresses (Ethernet addresses) of the devices on each of its network interfaces. It forwards traffic between two networks only when its source and destination are on different networks.
In many respects, a bridge is like an Ethernet switch with very few ports.
There are two common situations in which a bridge is used today.
Situation one is where your physical network segment is overloaded with traffic, but you do not want for whatever reason to subnet the network and interconnect the subnets with a router.
Let us consider an example of a newspaper where the Editorial and Production departments are on the same subnetwork. The Editorial users all use server A for file service, and the Production users are on server B. An Ethernet is used to connect all users together, and high loads on the network are slowing things down.
If the Editorial users could be segregated on one network segment and the Production users on another, the two network segments could be connected with a bridge. Only the network traffic destined for interfaces on the ``other'' side of the bridge would be sent to the other network, reducing congestion on each network segment.
The second common situation is where firewall functionality is needed without IP Masquerading (NAT).
An example is a small company that is connected via DSL or ISDN to their ISP. They have a 13 globally-accessible IP addresses from their ISP and have 10 PCs on their network. In this situation, using a router-based firewall is difficult because of subnetting issues.
A bridge-based firewall can be configured and dropped into the path just downstream of their DSL/ISDN router without any IP numbering issues.
A bridge requires at least two network cards to function. Unfortunately, not all network interface cards as of FreeBSD 4.0 support bridging. Read bridge(4) for details on the cards that are supported.
Install and test the two network cards before continuing.
To enable kernel support for bridging, add the:
options BRIDGE
statement to your kernel configuration file, and rebuild your kernel.
If you are planning to use the bridge as a firewall, you will need to add the IPFIREWALL option as well. Read Section 10.8 for general information on configuring the bridge as a firewall.
If you need to allow non-IP packets (such as ARP) to flow through the bridge, there is an undocumented firewall option that must be set. This option is IPFIREWALL_DEFAULT_TO_ACCEPT. Note that this changes the default rule for the firewall to accept any packet. Make sure you know how this changes the meaning of your ruleset before you set it.
If you want to use the bridge as a traffic shaper, you will need to add the DUMMYNET option to your kernel configuration. Read dummynet(4) for further information.
Add the line:
net.link.ether.bridge=1
to /etc/sysctl.conf to enable the bridge at runtime, and the line:
net.link.ether.bridge_cfg=if1,if2
to enable bridging on the specified interfaces (replace if1 and if2 with the names of your two network interfaces). If you want the bridged packets to be filtered by ipfw(8), you should add:
net.link.ether.bridge_ipfw=1
as well.
If you want to be able to telnet into the bridge from the network, it is OK to assign one of the network cards an IP address. The consensus is that assigning both cards an address is a bad idea.
If you have multiple bridges on your network, there cannot be more than one path between any two workstations. Technically, this means that there is no support for spanning tree link management.
A bridge can add latency to your ping times, especially for traffic from one segment to another.
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the documentation before contacting <[email protected]>.
For questions about this documentation, e-mail <[email protected]>.