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 interfaces 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 several 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
bridge
N 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 filtering; 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 segments 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 knowledge 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 segment 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.
Using 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 Protocol without
rapid state transitions. Note that RSTP will be compatible with remote
bridges running common STP.
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
useful for snooping a bridged network passively on another host connected to
one of the span ports of the bridge. Span ports cannot be bridge members;
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
veb(4) and
tpmr(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 flagIFBIF_DISCOVER
is set, the interface will receive 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 interfaces has both flags set. If the flagIFBIF_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 withSIOCBRDGIFS
, 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 toIFBAF_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, respectively.
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 orIFBF_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
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 specific
interface. ifbr_name contains the name of the bridge
device, and ifbr_ifsname contains the name of the
bridge member interface.
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
orBRL_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 flagsBRL_FLAG_IN
andBRL_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
andBRL_FLAG_DSTVALID
flags. The ifbr_src field is the source address that triggers the rule (only considered if ifbr_flags has theBRL_FLAG_SRCVALID
bit set). The ifbr_src field is the destination address that triggers the rule (only considered if ifbr_flags has theBRL_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 withSIOCBRDGIFS
, 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 cannot 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.
SIOCBRDGSIFPROT
struct ifbreq *- Set the protection domain membership of the interface named in ifbr_ifsname to the value in ifbr_protected.
ERRORS
If the ioctl(2) call fails, errno(2) is set to one of the following values:
- [
ENOENT
] - For an add request, this means that the named interface 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 interfaces to and from bridges and to set the bridge interface flags.
- [
EFAULT
] - The buffer used in a
SIOCBRDGIFS
orSIOCBRDGRTS
request points outside of the process's allocated address 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 forwarded. 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
Ethernet 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 different 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 authentication and authorization material, such as
keys and certificates, to impersonate the protected host(s)).
SEE ALSO
errno(2), ioctl(2), arp(4), etherip(4), ip(4), ip6(4), ipsec(4), netintro(4), pf(4), tpmr(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.