BRIDGE (4) | Special files and drivers | Unix Manual Pages

SYNOPSIS

DESCRIPTION

.Bf -symbolic This bridge implementation is made obsolete by:
.Ef if_bridge(4)
.Bf -symbolic and will be removed from future releases.
.Ef

.Fx supports bridging on Ethernet-type interfaces, including VLANs. Bridging support can be either compiled into the kernel, or loaded at runtime as a kernel module.

A single
.Fx host can do bridging on independent sets of interfaces, which are called "clusters". Each cluster connects a set of interfaces, and is identified by a "cluster-ID" which is a number in the range 1..65535. A cluster in fact is very similar to what commercial switches call a "VLAN". Note however that there is no relation whatsoever between the cluster-ID and the IEEE 802.1q VLAN-ID which appears in the header of packets transmitted on the wire. In fact, in most cases there is no relation between the so-called ""VLAN identifier"" used in most commercial switches, and the IEEE 802.1q VLAN-ID.

By putting both physical and logical (vlan(4)) interfaces in the same cluster, a
.Fx box can also implement what in commercial terms is called a "trunk" interface. This means that packets coming from one of the interfaces in a cluster will appear on the wire of the "parent" interface of any VLAN interface in a cluster, with the proper VLAN tag. Similarly, packets coming from a parent interface of any VLAN interface in a cluster will have the VLAN tag stripped, and will be forwarded to other interfaces in a cluster. See the EXAMPLES section for more details.

Runtime operation of the bridge is controlled by several sysctl(8) variables, as follows.

net.link.ether.bridge.enable
Set to 1 to enable bridging, set to 0 to disable it.

net.link.ether.bridge.ipfw
Set to 1 to enable ipfw(8) processing of bridged packets. Note that ipfw(8) rules only apply to IP packets. Non-IP packets are accepted by default. See the BUGS section and the ipfw(8) manpage for more details on the interaction of bridging and the firewall.

net.link.ether.bridge.ipf
Set to 1 to enable ipf(8) processing of bridged packets. Note that ipf(8) rules only apply to IP packets. Non-IP packets are accepted by default.

net.link.ether.bridge.config
Set to the list of interfaces to bridge. Interfaces are separated by spaces, commas or tabs. Each interface can be optionally followed by a colon and an integer indicating the cluster it belongs to (defaults to 1 if the cluster-ID is missing), e.g. ""dc0:1,dc1,vlan0:3 dc2:3"" will put dc0 and dc1 in cluster number 1, and vlan0 and dc2 in cluster number 3. See the EXAMPLES section for more examples.
The list of interfaces is rescanned every time the list is modified, bridging is enabled, or new interfaces are created or destroyed. An explicit request to refresh the bridge configuration can also be done by writing any value to net.link.ether.bridge.refresh. Interfaces that are in the list but cannot be used for bridging (because they are non-existing, or not Ethernet or VLAN) are not used and a warning message is generated.

Bridging requires interfaces to be put in promiscuous mode, and transmit packets with Ethernet source addresses different than their own. Some interfaces (e.g. wi(4)) do not support this functionality. Also, bridging is not compatible with interfaces which use hardware loopback, because there is no way to tell locally generated packets from externally generated ones.

FILES

/boot/kernel/bridge.ko bridge loadable module.

EXAMPLES

A simple bridge configuration with three interfaces in the same cluster can be set as follows. No cluster-ID is specified here, which will cause the interfaces to appear as part of cluster #1.

"sysctl net.link.ether.bridge.config=dc0,dc1,fxp1"

If you do not know what actual interfaces will be present on your system, you can just put all existing interfaces in the configuration, as follows:

sysctl net.link.ether.bridge.config= "‘ifconfig -l‘"

This will result in a space-separated list of interfaces. Out of the list, only Ethernet and VLAN interfaces will be used for bridging, whereas for others the kernel will produce a warning message.

More complex configurations can be used to create multiple clusters, e.g.

"sysctl net.link.ether.bridge.config=dc0:3,dc1:3,fxp0:4,fxp1:4"

will create two completely independent clusters.

Finally, interesting configurations involve VLANs and parent interfaces. As an example, the following configuration will use interface dc0 as a "trunk" interface, and pass packets for 802.1q VLANs 10 and 20 to physical interfaces dc1 and dc2, respectively:
sysctl net.link.ether.bridge.config=vlan0:34,dc1:34,vlan1:56,dc2:56
ifconfig vlan0 vlan 10 vlandev dc0
ifconfig vlan1 vlan 20 vlandev dc0

Note how there is no relation between the 802.1q VLAN identifiers (10 and 20) and the cluster-ID’s (34 and 56) used in the bridge.config variable.

Note also that the trunk interface does not even appear in the bridge.config, as VLAN tag insertion/removal is performed by the vlan(4) devices. When using VLAN devices, care must be taken by not creating loops between these devices and their parent interfaces.

HISTORY

BUGS

ipfw(8), ipfw(8)

greatis just4fun network

NAME