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

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 inter-
     faces, 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 whatso-
     ever 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	FreeBSD	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)	vari-
     ables, 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)	man-
	     page 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 sepa-
	     rated by spaces, commas or	tabs.  Each interface can be option-
	     ally 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 num-
	     ber 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.	 An explicit request to	refresh	the bridge configura-
	     tion 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, bridg-
     ing 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.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 fol-
     lows:

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

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.

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

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

FreeBSD	9.3		      September	20, 2003		   FreeBSD 9.3

NAME | SYNOPSIS | DESCRIPTION | EXAMPLES | BUGS | FILES | 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+5.3-RELEASE>

home | help