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

FreeBSD Manual Pages

  
 
  

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

NAME
     bridge -- Ethernet	bridge interface

SYNOPSIS
     pseudo-device bridge

     #include <sys/types.h>
     #include <net/if.h>
     #include <netinet/in.h>
     #include <netinet/if_ether.h>
     #include <net/if_bridge.h>

DESCRIPTION
     The bridge	device creates a logical link between two or more Ethernet in-
     terfaces or encapsulation interfaces (see etherip(4)).  This link between
     the interfaces selectively	forwards frames	from each interface on the
     bridge to every other interface on	the bridge.  A bridge can serve	sev-
     eral services, including isolation	of traffic between sets	of machines so
     that traffic local	to one set of machines is not available	on the wire of
     another set of machines, and it can act as	a transparent filter for ip(4)
     datagrams.

     A bridge interface	can be created at runtime using	the ifconfig bridgeN
     create command or by setting up a hostname.if(5) configuration file for
     netstart(8).

     The bridges provided by this interface are	learning bridges with filter-
     ing; see pf(4).  In general a bridge works	like a hub, forwarding traffic
     from one interface	to another.  It	differs	from a hub in that it will
     "learn" which machines are	on each	of its attached	segments by actively
     listening to incoming traffic and examining the headers of	each frame.  A
     table is built containing the MAC address and segment to which the	MAC
     address is	attached.  This	allows a bridge	to be more selective about
     what it forwards, which can be used to reduce traffic on a	set of seg-
     ments and also to provide an IP firewall without changing the topology of
     the network.

     The algorithm works as follows by default,	but can	be modified via
     ioctl(2) or the utility ifconfig(8).  When	a frame	comes in, the origin
     segment and the source address are	recorded.  If the bridge has no	knowl-
     edge about	where the destination is to be found, the bridge will forward
     the frame to all attached segments.  If the destination is	known to be on
     a different segment from its origin, the bridge will forward the packet
     only to the destination segment.  If the destination is on	the same seg-
     ment as the origin	segment, the bridge will drop the packet because the
     receiver has already had a	chance to see the frame.  Before forwarding a
     frame, the	bridge will check to see if the	packet contains	an ip(4) or
     ip6(4) datagram; if so, the datagram is run through the pf	interface so
     that it can be filtered.  See the NOTES section for details.

SPANNING TREE
     The bridge	has support for	802.1D-2004 Spanning Tree Protocol (STP),
     which can be used to detect and remove loops in a network topology.  Us-
     ing the stp or -stp commands to bridge, STP can be	enabled	or disabled on
     each port.

     The bridge	will use the Rapid Spanning Tree Protocol (RSTP) by default to
     allow rapid transitions to	the forwarding state.  The proto command to
     bridge can	be used	to force operation in the common Spanning Tree Proto-
     col without rapid state transitions.  Note	that RSTP will be compatible
     with remote bridges running common	STP.

     STP will not work on etherip(4) members because they lack a hardware MAC
     address.

SPAN PORTS
     The bridge	can have interfaces added to it	as span	ports.	Span ports
     transmit a	copy of	every frame received by	the bridge.  This is most use-
     ful for snooping a	bridged	network	passively on another host connected to
     one of the	span ports of the bridge.  Span	ports cannot be	bridge mem-
     bers; instead, the	addspan	and delspan commands are used to add and
     delete span ports to and from a bridge.

IOCTLS
     A bridge interface	responds to all	of the ioctl(2)	calls specific to
     other interfaces listed in	netintro(4).  The following ioctl(2) calls are
     specific to bridge	devices.  They are defined in <sys/sockio.h>.  Some
     ioctl(2) calls are	used by	switch(4) as well.

     SIOCBRDGIFS struct	ifbifconf *
	     Retrieve member interface list from a bridge.  This request takes
	     an	ifbifconf structure (see below)	as a value-result parameter.
	     The ifbic_len field should	be initially set to the	size of	the
	     buffer pointed to by ifbic_buf.  On return	it will	contain	the
	     length, in	bytes, of the configuration list.

	     Alternatively, if the ifbic_len passed in is set to 0,
	     SIOCBRDGIFS will set ifbic_len to the size	that ifbic_buf needs
	     to	be to fit the entire configuration list, and will not fill in
	     the other parameters.  This is useful for determining the exact
	     size that ifbic_buf needs to be in	advance.

	     The argument structure is defined as follows:

	     struct ifbreq {
		     char      ifbr_name[IFNAMSIZ];   /* bridge	ifs name */
		     char      ifbr_ifsname[IFNAMSIZ];/* member	ifs name */
		     u_int32_t ifbr_ifsflags;  /* member ifs flags */
		     u_int8_t  ifbr_state;     /* member stp state */
		     u_int8_t  ifbr_priority;  /* member stp priority */
		     u_int32_t ifbr_portno;    /* member port number */
		     u_int32_t ifbr_path_cost; /* member stp path cost */
	     };

	     /*	ifbr_ifsflags flags about interfaces */
	     #define IFBIF_LEARNING   0x0001 /*	ifs can	learn */
	     #define IFBIF_DISCOVER   0x0002 /*	sends packets w/unknown	dst */
	     #define IFBIF_BLOCKNONIP 0x0004 /*	ifs blocks non-IP/ARP in/out */
	     #define IFBIF_STP	      0x0008 /*	participate in spanning	tree*/
	     #define IFBIF_SPAN	      0x0100 /*	ifs is a span port (ro)	*/
	     #define IFBIF_RO_MASK    0xff00 /*	read only bits */

	     struct ifbifconf {
		     char      ifbic_name[IFNAMSIZ]; /*	bridge ifs name	*/
		     u_int32_t ifbic_len;	     /*	buffer size */
		     union {
			     caddr_t ifbicu_buf;
			     struct  ifbreq *ifbicu_req;
		     } ifbic_ifbicu;
	     #define ifbic_buf	     ifbic_ifbicu.ifbicu_buf
	     #define ifbic_req	     ifbic_ifbicu.ifbicu_req
	     };

     SIOCBRDGADD struct	ifbreq *
	     Add the interface named in	ifbr_ifsname to	the bridge named in
	     ifbr_name.

     SIOCBRDGDEL struct	ifbreq *
	     Delete the	interface named	in ifbr_ifsname	from the bridge	named
	     in	ifbr_name.

     SIOCBRDGADDS struct ifbreq	*
	     Add the interface named in	ifbr_ifsname as	a span port to the
	     bridge named in ifbr_name.

     SIOCBRDGDELS struct ifbreq	*
	     Delete the	interface named	in ifbr_ifsname	from the list of span
	     ports of the bridge named in ifbr_name.

     SIOCBRDGSIFFLGS struct ifbreq *
	     Set the bridge member interface flags for the interface named in
	     ifbr_ifsname attached to the bridge ifbr_name.  If	the flag
	     IFBIF_LEARNING is set on an interface, source addresses from
	     frames received on	the interface are recorded in the address
	     cache.  If	the flag IFBIF_DISCOVER	is set,	the interface will re-
	     ceive packets destined for	unknown	destinations, otherwise	a
	     frame that	has a destination not found in the address cache is
	     not forwarded to this interface.  The default for newly added in-
	     terfaces has both flags set.  If the flag IFBIF_BLOCKNONIP	is
	     set, only ip(4), ip6(4), arp(4), and Reverse ARP packets will be
	     bridged from and to the interface.

     SIOCBRDGGIFFLGS struct ifbreq *
	     Retrieve the bridge member	interface flags	for the	interface
	     named in ifbr_ifsname attached to the bridge ifbr_name.

     SIOCBRDGRTS struct	ifbaconf *
	     Retrieve the address cache	of the bridge named in ifbac_name.
	     This request takes	an ifbaconf structure (see below) as a value-
	     result parameter.	The ifbac_len field should be initially	set to
	     the size of the buffer pointed to by ifbac_buf.  On return, it
	     will contain the length, in bytes,	of the configuration list.

	     Alternatively, if the ifbac_len passed in is set to 0,
	     SIOCBRDGRTS will set it to	the size that ifbac_buf	needs to be to
	     fit the entire configuration list,	and will not fill in the other
	     parameters.  As with SIOCBRDGIFS, this is useful for determining
	     the exact size that ifbac_buf needs to be in advance.

	     The argument structure is defined as follows:

	     struct ifbareq {
		     char     ifba_name[IFNAMSIZ];   /*	bridge name */
		     char     ifba_ifsname[IFNAMSIZ];/*	destination ifs	*/
		     u_int8_t ifba_age;		     /*	address	age */
		     u_int8_t ifba_flags;	     /*	address	flags */
		     struct ether_addr ifba_dst;     /*	destination addr */
	     };

	     #define IFBAF_TYPEMASK  0x03	     /*	address	type mask */
	     #define IFBAF_DYNAMIC   0x00	     /*	dynamically learned */
	     #define IFBAF_STATIC    0x01	     /*	static address */

	     struct ifbaconf {
		     char      ifbac_name[IFNAMSIZ]; /*	bridge ifs name	*/
		     u_int32_t ifbac_len;	     /*	buffer size */
		     union {
			     caddr_t ifbacu_buf;     /*	buffer */
			     struct ifbareq *ifbacu_req; /* request pointer */
		     } ifbac_ifbacu;
	     #define ifbac_buf	     ifbac_ifbacu.ifbacu_buf
	     #define ifbac_req	     ifbac_ifbacu.ifbacu_req
	     };

	     Address cache entries with	the type set to	IFBAF_DYNAMIC in
	     ifba_flags	are entries learned by the bridge.  Entries with the
	     type set to IFBAF_STATIC are manually added entries.

     SIOCBRDGSADDR struct ifbareq *
	     Add an entry, manually, to	the address cache for the bridge named
	     in	ifba_name.  The	address	and its	associated interface and flags
	     are set in	the ifba_dst, ifba_ifsname, and	ifba_flags fields, re-
	     spectively.

     SIOCBRDGDADDR struct ifbareq *
	     Delete an entry from the address cache of the bridge named	in
	     ifba_name.	 Entries are deleted strictly based on the address
	     field ifba_dst.

     SIOCBRDGFLUSH struct ifbreq *
	     Flush addresses from the cache.  ifbr_name	contains the name of
	     the bridge	device,	and ifbr_ifsflags should be set	to
	     IFBF_FLUSHALL to flush all	addresses from the cache or
	     IFBF_FLUSHDYN to flush only the dynamically learned addresses
	     from the cache.

     SIOCBRDGSCACHE struct ifbrparam *
	     Set the maximum address cache size	for the	bridge named in
	     ifbrp_name	to ifbrp_csize entries.

	     The argument structure is as follows:

	     struct ifbrparam {
		     char	       ifbrp_name[IFNAMSIZ];
		     union {
			     u_int32_t ifbrpu_csize;	 /* cache size */
			     int       ifbrpu_ctime;	 /* cache time */
			     u_int16_t ifbrpu_prio;	 /* bridge priority */
			     u_int8_t  ifbrpu_hellotime; /* hello time */
			     u_int8_t  ifbrpu_fwddelay;	 /* fwd	delay */
			     u_int8_t  ifbrpu_maxage;	 /* max	age */
			     u_int64_t ifbrpu_datapath;	 /* datapath-id	*/
			     u_int32_t ifbrpu_maxgroup;	 /* group size */
		     } ifbrp_ifbrpu;
	     };
	     #define ifbrp_csize     ifbrp_ifbrpu.ifbrpu_csize
	     #define ifbrp_ctime     ifbrp_ifbrpu.ifbrpu_ctime
	     #define ifbrp_prio	     ifbrp_ifbrpu.ifbrpu_prio
	     #define ifbrp_hellotime ifbrp_ifbrpu.ifbrpu_hellotime
	     #define ifbrp_fwddelay  ifbrp_ifbrpu.ifbrpu_fwddelay
	     #define ifbrp_maxage    ifbrp_ifbrpu.ifbrpu_maxage
	     #define ifbrp_datapath  ifbrp_ifbrpu.ifbrpu_datapath
	     #define ifbrp_maxflow   ifbrp_ifbrpu.ifbrpu_csize
	     #define ifbrp_maxgroup  ifbrp_ifbrpu.ifbrpu_maxgroup

	     Note that the ifbrp_ctime,	ifbrp_hellotime, ifbrp_fwddelay	and
	     ifbrp_maxage fields are in	seconds.

     SIOCBRDGGCACHE struct ifbrparam *
	     Retrieve the maximum size of the address cache for	the bridge
	     ifbrp_name.

     SIOCBRDGSTO struct	ifbrparam *
	     Set the time, in seconds, for how long addresses which have not
	     been seen on the network (i.e., have not transmitted a packet)
	     will remain in the	cache to the value ifbrp_ctime.	 If the	time
	     is	set to zero, no	aging is performed on the address cache.

     SIOCBRDGGTO struct	ifbrparam *
	     Retrieve the address cache	expiration time	(see above).

     SIOCBRDGARL struct	ifbrlreq *
	     Add an Ethernet address filtering rule to the bridge on a spe-
	     cific interface.  ifbr_name contains the name of the bridge de-
	     vice, and ifbr_ifsname contains the name of the bridge member in-
	     terface.

	     Rules are applied in the order in which they were added to	the
	     bridge, and the first matching rule's action parameter determines
	     the fate of the packet.  The ifbr_action field is one of
	     BRL_ACTION_PASS or	BRL_ACTION_BLOCK, to pass or block matching
	     frames, respectively.  The	ifbr_flags field specifies whether the
	     rule should match on input, output, or both by using the flags
	     BRL_FLAG_IN and BRL_FLAG_OUT.  At least one of these flags	must
	     be	set.

	     The ifbr_flags field also specifies whether either	(or both) of
	     the source	and destination	addresses should be matched by using
	     the BRL_FLAG_SRCVALID and BRL_FLAG_DSTVALID flags.	 The ifbr_src
	     field is the source address that triggers the rule	(only consid-
	     ered if ifbr_flags	has the	BRL_FLAG_SRCVALID bit set).  The
	     ifbr_src field is the destination address that triggers the rule
	     (only considered if ifbr_flags has	the BRL_FLAG_DSTVALID bit
	     set).  If neither bit is set, the rule matches all	frames.

	     The argument structure is as follows:

	     struct ifbrlreq {
		     char     ifbr_name[IFNAMSIZ];    /* bridge	ifs name */
		     char     ifbr_ifsname[IFNAMSIZ]; /* member	ifs name */
		     u_int8_t ifbr_action;	      /* disposition */
		     u_int8_t ifbr_flags;	      /* flags */
		     struct ether_addr ifbr_src;      /* source	mac */
		     struct ether_addr ifbr_dst;      /* destination mac */
		     char     ifbr_tagname[PF_TAG_NAME_SIZE]; /* pf tagname */
	     };
	     #define BRL_ACTION_BLOCK	     0x01     /* block frame */
	     #define BRL_ACTION_PASS	     0x02     /* pass frame */
	     #define BRL_FLAG_IN	     0x08     /* input rule */
	     #define BRL_FLAG_OUT	     0x04     /* output	rule */
	     #define BRL_FLAG_SRCVALID	     0x02     /* src valid */
	     #define BRL_FLAG_DSTVALID	     0x01     /* dst valid */

     SIOCBRDGFRL struct	ifbrlreq *
	     Remove all	filtering rules	from a bridge interface	member.
	     ifbr_name contains	the name of the	bridge device, and
	     ifbr_ifsname contains the name of the bridge member interface.

     SIOCBRDGGRL struct	ifbrlconf *
	     Retrieve all of the rules from the	bridge,	ifbrl_name, for	the
	     member interface, ifbrl_ifsname.  This request takes an ifbrlconf
	     structure (see below) as a	value-result parameter.	 The ifbrl_len
	     field should be initially set to the size of the buffer pointed
	     to	by ifbrl_buf.  On return, it will contain the length, in
	     bytes, of the configuration list.

	     Alternatively, if the ifbrl_len passed in is set to 0,
	     SIOCBRDGGRL will set it to	the size that ifbrl_buf	needs to be to
	     fit the entire configuration list,	and will not fill in the other
	     parameters.  As with SIOCBRDGIFS, this is useful for determining
	     the exact size that ifbrl_buf needs to be in advance.

	     The argument structure is defined as follows:

	     struct ifbrlconf {
		     char      ifbrl_name[IFNAMSIZ];	/* bridge ifs name */
		     char      ifbrl_ifsname[IFNAMSIZ];	/* member ifs name */
		     u_int32_t ifbrl_len;		/* buffer size */
		     union {
			     caddr_t ifbrlu_buf;
			     struct  ifbrlreq *ifbrlu_req;
		     } ifbrl_ifbrlu;
	     #define ifbrl_buf ifbrl_ifbrlu.ifbrlu_buf
	     #define ifbrl_req ifbrl_ifbrlu.ifbrlu_req
	     };

     SIOCBRDGGPRI struct ifbrparam *
	     Retrieve the Spanning Tree	Protocol (STP) priority	parameter of
	     the bridge	into the ifbrp_prio field.

     SIOCBRDGSPRI struct ifbrparam *
	     Set the STP priority parameter of the bridge to the value in
	     ifbrp_prio.

     SIOCBRDGGHT struct	ifbrparam *
	     Retrieve the STP hello time parameter, in seconds,	of the bridge
	     into the ifbrp_hellotime field.

     SIOCBRDGSHT struct	ifbrparam *
	     Set the STP hello time parameter, in seconds, of the bridge to
	     the value in ifbrp_hellotime.  The	value in ifbrp_hellotime can-
	     not be zero.

     SIOCBRDGGFD struct	ifbrparam *
	     Retrieve the STP forward delay parameter, in seconds, of the
	     bridge into the ifbrp_fwddelay field.

     SIOCBRDGSFD struct	ifbrparam *
	     Set the STP forward delay parameter, in seconds, of the bridge to
	     the value in ifbrp_fwddelay.  The value in	ifbrp_fwddelay cannot
	     be	zero.

     SIOCBRDGGMA struct	ifbrparam *
	     Retrieve the STP maximum age parameter, in	seconds, of the	bridge
	     into the ifbrp_maxage field.

     SIOCBRDGSMA struct	ifbrparam *
	     Set the STP maximum age parameter,	in seconds, of the bridge to
	     the value in ifbrp_maxage.	 The value in ifbrp_maxage cannot be
	     zero.

     SIOCBRDGSIFPRIO struct ifbreq *
	     Set the STP priority parameter of the interface named in
	     ifbr_ifsname to the value in ifbr_priority.

     SIOCBRDGSIFCOST struct ifbreq *
	     Set the STP cost parameter	of the interface named in ifbr_ifsname
	     to	the value in ifbr_path_cost.  The value	in ifbr_path_cost must
	     be	greater	than or	equal to one.

ERRORS
     If	the ioctl(2) call fails, errno(2) is set to one	of the following val-
     ues:

     [ENOENT]		For an add request, this means that the	named inter-
			face is	not configured into the	system.	 For a delete
			operation, it means that the named interface is	not a
			member of the bridge.  For an address cache deletion,
			the address was	not found in the table.

     [ENOMEM]		Memory could not be allocated for an interface or
			cache entry to be added	to the bridge.

     [EEXIST]		The named interface is already a member	of the bridge.

     [EBUSY]		The named interface is already a member	of another
			bridge.

     [EINVAL]		The named interface is not an Ethernet interface, or
			an invalid ioctl was performed on the bridge.

     [ENETDOWN]		Address	cache operation	(flush,	add, or	delete)	on a
			bridge that is in the down state.

     [EPERM]		Super-user privilege is	required to add	and delete in-
			terfaces to and	from bridges and to set	the bridge in-
			terface	flags.

     [EFAULT]		The buffer used	in a SIOCBRDGIFS or SIOCBRDGRTS	re-
			quest points outside of	the process's allocated	ad-
			dress space.

     [ESRCH]		No such	member interface in the	bridge.

NOTES
     Bridged packets pass through pf(4)	filters	once as	input on the receiving
     interface and once	as output on all interfaces on which they are for-
     warded.  In order to pass through the bridge packets must pass any	in
     rules on the input	and any	out rules on the output	interface.  Packets
     may be blocked either entering or leaving the bridge.

     Return packets generated by pf itself are not routed using	the kernel
     routing table.  Instead, pf will send these replies back to the same Eth-
     ernet address that	the original packet came from.	This applies to	rules
     with return, return-rst, return-icmp, return-icmp6, or synproxy defined.
     At	the moment, only return-rst on IPv4 is implemented and the other
     packet generating rules are unsupported.

     If	an IP packet is	too large for the outgoing interface, the bridge will
     perform IP	fragmentation.	This can happen	when bridge members have dif-
     ferent MTUs or when IP fragments are reassembled by pf.  Non-IP packets
     which are too large for the outgoing interface will be dropped.

     If	the IFF_LINK2 flag is set on the bridge	interface, the bridge will
     also perform transparent ipsec(4) processing on the packets (encrypt or
     decrypt them), according to the policies set with the ipsecctl(8) command
     by	the administrator.  If appropriate security associations (SAs) do not
     exist, any	key management daemons such as isakmpd(8) that are running on
     the bridge	will be	invoked	to establish the necessary SAs.	 These daemons
     have to be	configured as if they were running on the host whose traffic
     they are protecting (i.e.,	they need to have the appropriate authentica-
     tion and authorization material, such as keys and certificates, to	imper-
     sonate the	protected host(s)).

SEE ALSO
     errno(2), ioctl(2), arp(4), etherip(4), ip(4), ip6(4), ipsec(4),
     netintro(4), pf(4), switch(4), vether(4), hostname.if(5), ifconfig(8),
     ipsecctl(8), isakmpd(8), netstart(8)

HISTORY
     The bridge	kernel interface first appeared	in OpenBSD 2.5.

AUTHORS
     The bridge	kernel interface was written by	Jason L. Wright
     <jason@thought.net> as part of an undergraduate independent study at the
     University	of North Carolina at Greensboro.

     Support for rapid spanning	tree reconfigurations (RSTP) was added by
     Andrew Thompson <thompsa@freebsd.org> and ported to OpenBSD by
     Reyk Floeter <reyk@openbsd.org>.

BUGS
     There are some rather special network interface chipsets which will not
     work in a bridge configuration.  Some chipsets have serious flaws when
     running in	promiscuous mode, like the TI ThunderLAN (see tl(4)), which
     receives its own transmissions (this renders the address learning cache
     useless).	Most other chipsets work fine though.

BSD			       October 24, 2017				   BSD

NAME | SYNOPSIS | DESCRIPTION | SPANNING TREE | SPAN PORTS | IOCTLS | ERRORS | NOTES | SEE ALSO | HISTORY | AUTHORS | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=bridge&sektion=4&manpath=OpenBSD+6.5>

home | help