Written by Steve Peterson <steve@zpfe.com>.
It is sometimes useful to divide one physical network (i.e., 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. and a FreeBSD system with two network interface cards can act as a bridge.
The bridge works by learning the MAC layer addresses (i.e., 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 don't want for whatever reason to subnet the network and interconnect the subnets with a router.
Let's 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 address global IP allocation for 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 8.7 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. If you want the bridged packets to be filtered by ipfw, you should also add
net.link.ether.bridge_ipfw=1
as well.
My bridge/firewall is a Pentium 90 with one 3Com 3C900B and one 3C905B. The protected side of the network runs at 10mbps half duplex and the connection between the bridge and my router (a Cisco 675) runs at 100mbps full duplex. With no filtering enabled, I've found that the bridge adds about 0.4 milliseconds of latency to pings from the protected 10mbps network to the Cisco 675.
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.