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

FreeBSD Manual Pages


home | help
BRIDGE(4)		 BSD Kernel Interfaces Manual		     BRIDGE(4)

     bridge -- bridging	support

     options BRIDGE
     kldload /modules/bridge.ko

     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 re-
     lation 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.
	     set to 1 to enable	bridging, set to 0 to disable it.
	     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
	     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 de-
	     stroyed. 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.

     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.


     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-

	   sysctl"`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.


     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:

	   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) de-
     vices.  When using	vlan devices, care must	be taken by not	creating loops
     between these devices and their parent interfaces.

     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.

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

     Bridging was introduced in	FreeBSD	2.2.8 by Luigi Rizzo

BSD			       February	15, 2002			   BSD


Want to link to this manual page? Use this URL:

home | help