bridge(4)

NAME

bridge - bridging support

SYNOPSIS

options BRIDGE

DESCRIPTION

This bridge implementation is made obsolete by: if_bridge(4)

and will be
removed from future releases.

FreeBSD supports bridging on Ethernet-type interfaces, in

cluding VLANs.
Bridging support can be either compiled into the kernel, or

loaded at
runtime as a kernel module.

A single FreeBSD 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 num

ber 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 re

lation 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 identifi

er'' 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 FreeBSD box can also implement what in commercial

terms is
called a ``trunk'' interface. This means that packets com

ing 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 prop

er 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 miss

ing), 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 configura

tion, 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 mes

sage.

More complex configurations can be used to create multiple

clusters, e.g.

sysctl net.link.ether.bridge.con

fig=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 inter

face 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.con

fig=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 iden

tifiers (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.

SEE ALSO

ip(4), ng_bridge(4), vlan(4), ipf(8), ipfw(8), sysctl(8)

HISTORY

Bridging was introduced in FreeBSD 2.2.8 by Luigi Rizzo
<luigi@iet.unipi.it>.

BUGS

Care must be taken not to construct loops in the bridge

topology. The
kernel supports only a primitive form of loop detection, by

disabling
some interfaces when a loop is detected. No support for a

daemon running
the spanning tree algorithm is currently provided.

With bridging active, interfaces are in promiscuous mode,

thus causing
some load on the system to receive and filter out undesired

traffic.

When passing bridged packets to ipfw(8), remember that only

IP packets
are passed to the firewall, while other packets are silently

accepted.
Also remember that bridged packets are accepted after the

first pass
through the firewall irrespective of the setting of the

sysctl variable
net.inet.ip.fw.one_pass, and that some ipfw(8) actions such

as divert do
not apply to bridged packets. It might be useful to have a

rule of the
form

skipto 20000 ip from any to any bridged

near the beginning of your ruleset to implement specific

rulesets for
bridged packets.

BSD September 27, 2005

BSD