Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
BRIDGE(4)              FreeBSD Kernel Interfaces Manual              BRIDGE(4)

NAME
     bridge -- bridging support

SYNOPSIS
     options BRIDGE
     kldload /modules/bridge.ko

DESCRIPTION
     FreeBSD 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 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 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 (vlanX) interfaces in the same clus-
     ter, a FreeBSD box can also implement what in commercial terms is called
     a "trunk" interface. This means packets coming from one of the interfaces
     in the cluster, will appear on the wire on the "parent" interfaces of any
     vlan interface belonging to the cluster, with the proper VLAN tag. Simi-
     larly, packets coming from a parent interface, will have the VLAN tag
     stripped and will be forwarded to other interfaces on the same cluster.
     See the EXAMPLES section for more details.

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

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

     net.link.ether.bridge_ipfw
             set to 1 to enable ipfw(8) filtering on 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) man-
             page for more details on the interaction of bridging and the
             firewall.

     net.link.ether.bridge_cfg
             contains a list of interfaces on which bridging is to be per-
             formed.  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 clus-
             ter-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 modi-
             fied, bridging is enabled, or new interfaces are created or
             destroyed. 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.  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.

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_cfg=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 fol-
     lows:

           sysctl net.link.ether.bridge_cfg="`ifconfig -l`"

     This will result in a space-separated list of interfaces.  Out of the
     list, only Ethernet or 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_cfg=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 physi-
     cal interfaces dc1 and dc2:

           sysctl net.link.ether.bridge_cfg=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_cfg variable.

     Note also that the trunk interface does not even appear in the
     bridge_cfg, 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.

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

SEE ALSO
     ip(4), ng_bridge(4), vlan(4), ipfw(8), sysctl(8)

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

FreeBSD 4.10                   February 15, 2002                  FreeBSD 4.10

NAME | SYNOPSIS | DESCRIPTION | EXAMPLES | BUGS | SEE ALSO | HISTORY

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=bridge&sektion=4&manpath=FreeBSD+4.10-RELEASE>

home | help