diff options
Diffstat (limited to 'static/openbsd/man4/bridge.4')
| -rw-r--r-- | static/openbsd/man4/bridge.4 | 703 |
1 files changed, 703 insertions, 0 deletions
diff --git a/static/openbsd/man4/bridge.4 b/static/openbsd/man4/bridge.4 new file mode 100644 index 00000000..58e6c1aa --- /dev/null +++ b/static/openbsd/man4/bridge.4 @@ -0,0 +1,703 @@ +.\" $OpenBSD: bridge.4,v 1.83 2022/03/31 17:27:20 naddy Exp $ +.\" +.\" Copyright (c) 1999-2001 Jason L. Wright (jason@thought.net) +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE +.\" DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, +.\" INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES +.\" (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +.\" SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, +.\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +.\" ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd $Mdocdate: March 31 2022 $ +.Dt BRIDGE 4 +.Os +.Sh NAME +.Nm bridge +.Nd Ethernet bridge interface +.Sh SYNOPSIS +.Cd "pseudo-device bridge" +.Pp +.In sys/types.h +.In net/if.h +.In netinet/in.h +.In netinet/if_ether.h +.In net/if_bridge.h +.Sh DESCRIPTION +The +.Nm +device creates a logical link between two or more Ethernet interfaces or +encapsulation interfaces (see +.Xr 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 +.Xr ip 4 +datagrams. +.Pp +A +.Nm +interface can be created at runtime using the +.Ic ifconfig bridge Ns Ar N Ic create +command or by setting up a +.Xr hostname.if 5 +configuration file for +.Xr netstart 8 . +.Pp +The bridges provided by this interface are learning bridges with +filtering; see +.Xr 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. +.Pp +The algorithm works as follows by default, but can be modified via +.Xr ioctl 2 +or the utility +.Xr 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 +.Xr ip 4 +or +.Xr ip6 4 +datagram; if so, the datagram is run through the +pf interface so that it can be filtered. +See the +.Sx NOTES +section for details. +.Sh 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 +.Cm stp +or +.Cm -stp +commands +to +.Nm , +STP can be enabled or disabled on each port. +.Pp +The bridge will use the Rapid Spanning Tree Protocol (RSTP) by default +to allow rapid transitions to the forwarding state. +The +.Cm proto +command to +.Nm +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. +.Sh 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 +.Cm addspan +and +.Cm delspan +commands are used to add and delete span ports to and from a bridge. +.Sh IOCTLS +A +.Nm +interface responds to all of the +.Xr ioctl 2 +calls specific to other interfaces listed in +.Xr netintro 4 . +The following +.Xr ioctl 2 +calls are specific to +.Nm +devices. +They are defined in +.In sys/sockio.h . +Some +.Xr ioctl 2 +calls are used by +.Xr veb 4 +and +.Xr tpmr 4 +as well. +.Bl -tag -width Ds +.It Dv SIOCBRDGIFS Fa "struct ifbifconf *" +Retrieve member interface list from a bridge. +This request takes an +.Vt ifbifconf +structure (see below) as a value-result parameter. +The +.Va ifbic_len +field should be initially set to the size of the buffer +pointed to by +.Va ifbic_buf . +On return it will contain the length, in bytes, of the configuration +list. +.Pp +Alternatively, if the +.Va ifbic_len +passed in is set to 0, +.Dv SIOCBRDGIFS +will set +.Va ifbic_len +to the size that +.Va 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 +.Va ifbic_buf +needs to be in advance. +.Pp +The argument structure is defined as follows: +.Bd -literal +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 +}; +.Ed +.It Dv SIOCBRDGADD Fa "struct ifbreq *" +Add the interface named in +.Va ifbr_ifsname +to the bridge named in +.Va ifbr_name . +.It Dv SIOCBRDGDEL Fa "struct ifbreq *" +Delete the interface named in +.Va ifbr_ifsname +from the bridge named in +.Va ifbr_name . +.It Dv SIOCBRDGADDS Fa "struct ifbreq *" +Add the interface named in +.Va ifbr_ifsname +as a span port to the bridge named in +.Va ifbr_name . +.It Dv SIOCBRDGDELS Fa "struct ifbreq *" +Delete the interface named in +.Va ifbr_ifsname +from the list of span ports of the bridge named in +.Va ifbr_name . +.It Dv SIOCBRDGSIFFLGS Fa "struct ifbreq *" +Set the bridge member interface flags for the interface named in +.Va ifbr_ifsname +attached to the bridge +.Va ifbr_name . +If the flag +.Dv IFBIF_LEARNING +is set on an interface, source addresses from frames received on the +interface are recorded in the address cache. +If the flag +.Dv IFBIF_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 flag +.Dv IFBIF_BLOCKNONIP +is set, only +.Xr ip 4 , +.Xr ip6 4 , +.Xr arp 4 , +and +Reverse ARP packets will be bridged from and to the interface. +.It Dv SIOCBRDGGIFFLGS Fa "struct ifbreq *" +Retrieve the bridge member interface flags for the interface named in +.Va ifbr_ifsname +attached to the bridge +.Va ifbr_name . +.It Dv SIOCBRDGRTS Fa "struct ifbaconf *" +Retrieve the address cache of the bridge named in +.Va ifbac_name . +This request takes an +.Vt ifbaconf +structure (see below) as a value-result parameter. +The +.Va ifbac_len +field should be initially set to the size of the buffer pointed to by +.Va ifbac_buf . +On return, it will contain the length, in bytes, of the configuration list. +.Pp +Alternatively, if the +.Va ifbac_len +passed in is set to 0, +.Dv SIOCBRDGRTS +will set it to the size that +.Va ifbac_buf +needs to be to fit the entire configuration list, and will not fill in the other +parameters. +As with +.Dv SIOCBRDGIFS , +this is useful for determining the exact size that +.Va ifbac_buf +needs to be in advance. +.Pp +The argument structure is defined as follows: +.Bd -literal +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 +}; +.Ed +.Pp +Address cache entries with the type set to +.Dv IFBAF_DYNAMIC +in +.Va ifba_flags +are entries learned by the bridge. +Entries with the type set to +.Dv IFBAF_STATIC +are manually added entries. +.It Dv SIOCBRDGSADDR Fa "struct ifbareq *" +Add an entry, manually, to the address cache for the bridge named in +.Va ifba_name . +The address and its associated interface and flags are set in the +.Va ifba_dst , +.Va ifba_ifsname , +and +.Va ifba_flags +fields, respectively. +.It Dv SIOCBRDGDADDR Fa "struct ifbareq *" +Delete an entry from the address cache of the bridge named in +.Va ifba_name . +Entries are deleted strictly based on the address field +.Va ifba_dst . +.It Dv SIOCBRDGFLUSH Fa "struct ifbreq *" +Flush addresses from the cache. +.Va ifbr_name +contains the name of the bridge device, and +.Va ifbr_ifsflags +should be set to +.Dv IFBF_FLUSHALL +to flush all addresses from the cache or +.Dv IFBF_FLUSHDYN +to flush only the dynamically learned addresses from the cache. +.It Dv SIOCBRDGSCACHE Fa "struct ifbrparam *" +Set the maximum address cache size for the bridge named in +.Va ifbrp_name +to +.Va ifbrp_csize +entries. +.Pp +The argument structure is as follows: +.Bd -literal +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 +.Ed +.Pp +Note that the +.Va ifbrp_ctime , ifbrp_hellotime , ifbrp_fwddelay +and +.Va ifbrp_maxage +fields are in seconds. +.It Dv SIOCBRDGGCACHE Fa "struct ifbrparam *" +Retrieve the maximum size of the address cache for the bridge +.Va ifbrp_name . +.It Dv SIOCBRDGSTO Fa "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 +.Va ifbrp_ctime . +If the time is set to zero, no aging is performed on the address cache. +.It Dv SIOCBRDGGTO Fa "struct ifbrparam *" +Retrieve the address cache expiration time (see above). +.It Dv SIOCBRDGARL Fa "struct ifbrlreq *" +Add an Ethernet address filtering rule to the bridge on a specific interface. +.Va ifbr_name +contains the name of the bridge device, and +.Va ifbr_ifsname +contains the name of the bridge member interface. +.Pp +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 +.Va ifbr_action +field is one of +.Dv BRL_ACTION_PASS +or +.Dv BRL_ACTION_BLOCK , +to pass or block matching frames, respectively. +The +.Va ifbr_flags +field specifies whether the rule should match on input, output, or both +by using the flags +.Dv BRL_FLAG_IN +and +.Dv BRL_FLAG_OUT . +At least one of these flags must be set. +.Pp +The +.Va ifbr_flags +field +also specifies whether either (or both) of the source and destination +addresses should be matched by using the +.Dv BRL_FLAG_SRCVALID +and +.Dv BRL_FLAG_DSTVALID +flags. +The +.Va ifbr_src +field is the source address that triggers the rule (only considered if +.Va ifbr_flags +has the +.Dv BRL_FLAG_SRCVALID +bit set). +The +.Va ifbr_src +field is the destination address that triggers the rule (only considered if +.Va ifbr_flags +has the +.Dv BRL_FLAG_DSTVALID +bit set). +If neither bit is set, the rule matches all frames. +.Pp +The argument structure is as follows: +.Bd -literal +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 */ +.Ed +.It Dv SIOCBRDGFRL Fa "struct ifbrlreq *" +Remove all filtering rules from a bridge interface member. +.Va ifbr_name +contains the name of the bridge device, and +.Va ifbr_ifsname +contains the name of the bridge member interface. +.It Dv SIOCBRDGGRL Fa "struct ifbrlconf *" +Retrieve all of the rules from the bridge, +.Va ifbrl_name , +for the member interface, +.Va ifbrl_ifsname . +This request takes an +.Vt ifbrlconf +structure (see below) as a value-result parameter. +The +.Va ifbrl_len +field should be initially set to the size of the buffer pointed to by +.Va ifbrl_buf . +On return, it will contain the length, in bytes, of the configuration list. +.Pp +Alternatively, if the +.Va ifbrl_len +passed in is set to 0, +.Dv SIOCBRDGGRL +will set it to the size that +.Va ifbrl_buf +needs to be to fit the entire configuration list, and will not fill in the other +parameters. +As with +.Dv SIOCBRDGIFS , +this is useful for determining the exact size that +.Va ifbrl_buf +needs to be in advance. +.Pp +The argument structure is defined as follows: +.Bd -literal +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 +}; +.Ed +.It Dv SIOCBRDGGPRI Fa "struct ifbrparam *" +Retrieve the Spanning Tree Protocol (STP) priority parameter of the bridge into +the +.Va ifbrp_prio +field. +.It Dv SIOCBRDGSPRI Fa "struct ifbrparam *" +Set the STP priority parameter of the bridge to the value in +.Va ifbrp_prio . +.It Dv SIOCBRDGGHT Fa "struct ifbrparam *" +Retrieve the STP hello time parameter, in seconds, of the bridge into the +.Va ifbrp_hellotime +field. +.It Dv SIOCBRDGSHT Fa "struct ifbrparam *" +Set the STP hello time parameter, in seconds, of the bridge to the value in +.Va ifbrp_hellotime . +The value in +.Va ifbrp_hellotime +cannot be zero. +.It Dv SIOCBRDGGFD Fa "struct ifbrparam *" +Retrieve the STP forward delay parameter, in seconds, of the bridge into the +.Va ifbrp_fwddelay +field. +.It Dv SIOCBRDGSFD Fa "struct ifbrparam *" +Set the STP forward delay parameter, in seconds, of the bridge to the value in +.Va ifbrp_fwddelay . +The value in +.Va ifbrp_fwddelay +cannot be zero. +.It Dv SIOCBRDGGMA Fa "struct ifbrparam *" +Retrieve the STP maximum age parameter, in seconds, of the bridge into the +.Va ifbrp_maxage +field. +.It Dv SIOCBRDGSMA Fa "struct ifbrparam *" +Set the STP maximum age parameter, in seconds, of the bridge to the value in +.Va ifbrp_maxage . +The value in +.Va ifbrp_maxage +cannot be zero. +.It Dv SIOCBRDGSIFPRIO Fa "struct ifbreq *" +Set the STP priority parameter of the interface named in +.Va ifbr_ifsname +to the value in +.Va ifbr_priority . +.It Dv SIOCBRDGSIFCOST Fa "struct ifbreq *" +Set the STP cost parameter of the interface named in +.Va ifbr_ifsname +to the value in +.Va ifbr_path_cost . +The value in +.Va ifbr_path_cost +must be greater than or equal to one. +.It Dv SIOCBRDGSIFPROT Fa "struct ifbreq *" +Set the protection domain membership of the interface named in +.Va ifbr_ifsname +to the value in +.Va ifbr_protected . +.El +.Sh ERRORS +If the +.Xr ioctl 2 +call fails, +.Xr errno 2 +is set to one of the following values: +.Bl -tag -width Er +.It Bq Er 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. +.It Bq Er ENOMEM +Memory could not be allocated for an interface or cache entry +to be added to the bridge. +.It Bq Er EEXIST +The named interface is already a member of the bridge. +.It Bq Er EBUSY +The named interface is already a member of another bridge. +.It Bq Er EINVAL +The named interface is not an Ethernet interface, or an invalid ioctl +was performed on the bridge. +.It Bq Er ENETDOWN +Address cache operation (flush, add, or delete) on a bridge that is +in the down state. +.It Bq Er EPERM +Super-user privilege is required to add and delete interfaces to and from +bridges and to set the bridge interface flags. +.It Bq Er EFAULT +The buffer used in a +.Dv SIOCBRDGIFS +or +.Dv SIOCBRDGRTS +request points outside of the process's allocated address space. +.It Bq Er ESRCH +No such member interface in the bridge. +.El +.Sh NOTES +Bridged packets pass through +.Xr 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 +.Ar in +rules on the input and any +.Ar out +rules on the output interface. +Packets may be blocked either entering or leaving the bridge. +.Pp +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 +.Ic return , +.Ic return-rst , +.Ic return-icmp , +.Ic return-icmp6 , +or +.Ic synproxy +defined. +At the moment, only +.Ic return-rst +on IPv4 is implemented and the other packet generating rules +are unsupported. +.Pp +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. +.Pp +If the +.Dv IFF_LINK2 +flag is set on the +.Nm +interface, the bridge will also perform transparent +.Xr ipsec 4 +processing on the packets (encrypt or decrypt them), according to the +policies set with the +.Xr ipsecctl 8 +command by the administrator. +If appropriate security associations (SAs) do not exist, any key +management daemons such as +.Xr 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)). +.Sh SEE ALSO +.Xr errno 2 , +.Xr ioctl 2 , +.Xr arp 4 , +.Xr etherip 4 , +.Xr ip 4 , +.Xr ip6 4 , +.Xr ipsec 4 , +.Xr netintro 4 , +.Xr pf 4 , +.Xr tpmr 4 , +.Xr vether 4 , +.Xr hostname.if 5 , +.Xr ifconfig 8 , +.Xr ipsecctl 8 , +.Xr isakmpd 8 , +.Xr netstart 8 +.Sh HISTORY +The +.Nm +kernel interface first appeared in +.Ox 2.5 . +.Sh AUTHORS +The +.Nm +kernel interface was written by +.An Jason L. Wright Aq Mt jason@thought.net +as part of an undergraduate independent study at the +University of North Carolina at Greensboro. +.Pp +Support for rapid spanning tree reconfigurations (RSTP) was added by +.An Andrew Thompson Aq Mt thompsa@freebsd.org +and ported to +.Ox +by +.An Reyk Floeter Aq Mt reyk@openbsd.org . +.Sh 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 +.Xr tl 4 ) , +which receives its own transmissions (this renders the address learning +cache useless). +Most other chipsets work fine though. |