xref: /openbsd/share/man/man4/bridge.4 (revision 3cab2bb3)
1.\"	$OpenBSD: bridge.4,v 1.79 2019/08/16 05:33:50 jmc Exp $
2.\"
3.\" Copyright (c) 1999-2001 Jason L. Wright (jason@thought.net)
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\"
15.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
16.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
17.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
18.\" DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
19.\" INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
20.\" (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
21.\" SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
22.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
23.\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
24.\" ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
25.\" POSSIBILITY OF SUCH DAMAGE.
26.\"
27.Dd $Mdocdate: August 16 2019 $
28.Dt BRIDGE 4
29.Os
30.Sh NAME
31.Nm bridge
32.Nd Ethernet bridge interface
33.Sh SYNOPSIS
34.Cd "pseudo-device bridge"
35.Pp
36.In sys/types.h
37.In net/if.h
38.In netinet/in.h
39.In netinet/if_ether.h
40.In net/if_bridge.h
41.Sh DESCRIPTION
42The
43.Nm
44device creates a logical link between two or more Ethernet interfaces or
45encapsulation interfaces (see
46.Xr etherip 4 ) .
47This link between the interfaces selectively forwards frames from
48each interface on the bridge to every other interface on the bridge.
49A bridge can serve several services, including isolation of traffic between
50sets of machines so that traffic local to one set of machines is not
51available on the wire of another set of machines, and it can act as
52a transparent filter for
53.Xr ip 4
54datagrams.
55.Pp
56A
57.Nm
58interface can be created at runtime using the
59.Ic ifconfig bridge Ns Ar N Ic create
60command or by setting up a
61.Xr hostname.if 5
62configuration file for
63.Xr netstart 8 .
64.Pp
65The bridges provided by this interface are learning bridges with
66filtering; see
67.Xr pf 4 .
68In general a bridge works like a hub, forwarding traffic from one interface
69to another.
70It differs from a hub in that it will "learn" which machines
71are on each of its attached segments by actively listening to
72incoming traffic and examining the headers of each frame.
73A table is built containing the MAC address and segment to which the
74MAC address is attached.
75This allows a bridge to be more selective about what it forwards,
76which can be used to reduce traffic on a set of segments and also to provide
77an IP firewall without changing the topology of the network.
78.Pp
79The algorithm works as follows by default, but can be modified via
80.Xr ioctl 2
81or the utility
82.Xr ifconfig 8 .
83When a frame comes in, the origin segment and the source address are
84recorded.
85If the bridge has no knowledge about where the destination is to be found,
86the bridge will forward the frame to all attached segments.
87If the destination is known to be on a different segment from its origin, the
88bridge will forward the packet only to the destination segment.
89If the destination is on the same segment as the origin segment, the bridge
90will drop the packet because the receiver has already had a chance to see
91the frame.
92Before forwarding a frame, the bridge will check to see if the packet
93contains an
94.Xr ip 4
95or
96.Xr ip6 4
97datagram; if so, the datagram is run through the
98pf interface so that it can be filtered.
99See the
100.Sx NOTES
101section for details.
102.Sh SPANNING TREE
103The bridge has support for 802.1D-2004 Spanning Tree Protocol (STP),
104which can be used to detect and remove loops in a network topology.
105Using the
106.Cm stp
107or
108.Cm -stp
109commands
110to
111.Nm ,
112STP can be enabled or disabled on each port.
113.Pp
114The bridge will use the Rapid Spanning Tree Protocol (RSTP) by default
115to allow rapid transitions to the forwarding state.
116The
117.Cm proto
118command to
119.Nm
120can be used to force operation in the common Spanning Tree Protocol
121without rapid state transitions.
122Note that RSTP will be compatible with remote bridges running common STP.
123.Sh SPAN PORTS
124The bridge can have interfaces added to it as span ports.
125Span ports transmit a copy of every frame received by the bridge.
126This is most useful for snooping a bridged network passively on
127another host connected to one of the span ports of the bridge.
128Span ports cannot be bridge members; instead, the
129.Cm addspan
130and
131.Cm delspan
132commands are used to add and delete span ports to and from a bridge.
133.Sh IOCTLS
134A
135.Nm
136interface responds to all of the
137.Xr ioctl 2
138calls specific to other interfaces listed in
139.Xr netintro 4 .
140The following
141.Xr ioctl 2
142calls are specific to
143.Nm
144devices.
145They are defined in
146.In sys/sockio.h .
147Some
148.Xr ioctl 2
149calls are used by
150.Xr switch 4
151as well.
152.Bl -tag -width Ds
153.It Dv SIOCBRDGIFS Fa "struct ifbifconf *"
154Retrieve member interface list from a bridge.
155This request takes an
156.Vt ifbifconf
157structure (see below) as a value-result parameter.
158The
159.Va ifbic_len
160field should be initially set to the size of the buffer
161pointed to by
162.Va ifbic_buf .
163On return it will contain the length, in bytes, of the configuration
164list.
165.Pp
166Alternatively, if the
167.Va ifbic_len
168passed in is set to 0,
169.Dv SIOCBRDGIFS
170will set
171.Va ifbic_len
172to the size that
173.Va ifbic_buf
174needs to be to fit the entire configuration list,
175and will not fill in the other parameters.
176This is useful for determining the exact size that
177.Va ifbic_buf
178needs to be in advance.
179.Pp
180The argument structure is defined as follows:
181.Bd -literal
182struct ifbreq {
183	char	  ifbr_name[IFNAMSIZ];	 /* bridge ifs name */
184	char	  ifbr_ifsname[IFNAMSIZ];/* member ifs name */
185	u_int32_t ifbr_ifsflags;  /* member ifs flags */
186	u_int8_t  ifbr_state;	  /* member stp state */
187	u_int8_t  ifbr_priority;  /* member stp priority */
188	u_int32_t ifbr_portno;	  /* member port number */
189	u_int32_t ifbr_path_cost; /* member stp path cost */
190};
191
192/* ifbr_ifsflags flags about interfaces */
193#define	IFBIF_LEARNING	 0x0001 /* ifs can learn */
194#define	IFBIF_DISCOVER	 0x0002 /* sends packets w/unknown dst */
195#define	IFBIF_BLOCKNONIP 0x0004 /* ifs blocks non-IP/ARP in/out */
196#define	IFBIF_STP	 0x0008 /* participate in spanning tree*/
197#define	IFBIF_SPAN	 0x0100 /* ifs is a span port (ro) */
198#define	IFBIF_RO_MASK	 0xff00 /* read only bits */
199
200struct ifbifconf {
201	char	  ifbic_name[IFNAMSIZ];	/* bridge ifs name */
202	u_int32_t ifbic_len;		/* buffer size */
203	union {
204		caddr_t	ifbicu_buf;
205		struct	ifbreq *ifbicu_req;
206	} ifbic_ifbicu;
207#define	ifbic_buf	ifbic_ifbicu.ifbicu_buf
208#define	ifbic_req	ifbic_ifbicu.ifbicu_req
209};
210.Ed
211.It Dv SIOCBRDGADD Fa "struct ifbreq *"
212Add the interface named in
213.Va ifbr_ifsname
214to the bridge named in
215.Va ifbr_name .
216.It Dv SIOCBRDGDEL Fa "struct ifbreq *"
217Delete the interface named in
218.Va ifbr_ifsname
219from the bridge named in
220.Va ifbr_name .
221.It Dv SIOCBRDGADDS Fa "struct ifbreq *"
222Add the interface named in
223.Va ifbr_ifsname
224as a span port to the bridge named in
225.Va ifbr_name .
226.It Dv SIOCBRDGDELS Fa "struct ifbreq *"
227Delete the interface named in
228.Va ifbr_ifsname
229from the list of span ports of the bridge named in
230.Va ifbr_name .
231.It Dv SIOCBRDGSIFFLGS Fa "struct ifbreq *"
232Set the bridge member interface flags for the interface named in
233.Va ifbr_ifsname
234attached to the bridge
235.Va ifbr_name .
236If the flag
237.Dv IFBIF_LEARNING
238is set on an interface, source addresses from frames received on the
239interface are recorded in the address cache.
240If the flag
241.Dv IFBIF_DISCOVER
242is set, the interface will receive packets destined for unknown
243destinations, otherwise a frame that has a destination not found
244in the address cache is not forwarded to this interface.
245The default for newly added interfaces has both flags set.
246If the flag
247.Dv IFBIF_BLOCKNONIP
248is set, only
249.Xr ip 4 ,
250.Xr ip6 4 ,
251.Xr arp 4 ,
252and
253Reverse ARP packets will be bridged from and to the interface.
254.It Dv SIOCBRDGGIFFLGS Fa "struct ifbreq *"
255Retrieve the bridge member interface flags for the interface named in
256.Va ifbr_ifsname
257attached to the bridge
258.Va ifbr_name .
259.It Dv SIOCBRDGRTS Fa "struct ifbaconf *"
260Retrieve the address cache of the bridge named in
261.Va ifbac_name .
262This request takes an
263.Vt ifbaconf
264structure (see below) as a value-result parameter.
265The
266.Va ifbac_len
267field should be initially set to the size of the buffer pointed to by
268.Va ifbac_buf .
269On return, it will contain the length, in bytes, of the configuration list.
270.Pp
271Alternatively, if the
272.Va ifbac_len
273passed in is set to 0,
274.Dv SIOCBRDGRTS
275will set it to the size that
276.Va ifbac_buf
277needs to be to fit the entire configuration list, and will not fill in the other
278parameters.
279As with
280.Dv SIOCBRDGIFS ,
281this is useful for determining the exact size that
282.Va ifbac_buf
283needs to be in advance.
284.Pp
285The argument structure is defined as follows:
286.Bd -literal
287struct ifbareq {
288	char	 ifba_name[IFNAMSIZ];	/* bridge name */
289	char	 ifba_ifsname[IFNAMSIZ];/* destination ifs */
290	u_int8_t ifba_age;		/* address age */
291	u_int8_t ifba_flags;		/* address flags */
292	struct ether_addr ifba_dst;	/* destination addr */
293};
294
295#define	IFBAF_TYPEMASK	0x03		/* address type mask */
296#define	IFBAF_DYNAMIC	0x00		/* dynamically learned */
297#define	IFBAF_STATIC	0x01		/* static address */
298
299struct ifbaconf {
300	char	  ifbac_name[IFNAMSIZ];	/* bridge ifs name */
301	u_int32_t ifbac_len;		/* buffer size */
302	union {
303		caddr_t	ifbacu_buf;	/* buffer */
304		struct ifbareq *ifbacu_req; /* request pointer */
305	} ifbac_ifbacu;
306#define	ifbac_buf	ifbac_ifbacu.ifbacu_buf
307#define	ifbac_req	ifbac_ifbacu.ifbacu_req
308};
309.Ed
310.Pp
311Address cache entries with the type set to
312.Dv IFBAF_DYNAMIC
313in
314.Va ifba_flags
315are entries learned by the bridge.
316Entries with the type set to
317.Dv IFBAF_STATIC
318are manually added entries.
319.It Dv SIOCBRDGSADDR Fa "struct ifbareq *"
320Add an entry, manually, to the address cache for the bridge named in
321.Va ifba_name .
322The address and its associated interface and flags are set in the
323.Va ifba_dst ,
324.Va ifba_ifsname ,
325and
326.Va ifba_flags
327fields, respectively.
328.It Dv SIOCBRDGDADDR Fa "struct ifbareq *"
329Delete an entry from the address cache of the bridge named in
330.Va ifba_name .
331Entries are deleted strictly based on the address field
332.Va ifba_dst .
333.It Dv SIOCBRDGFLUSH Fa "struct ifbreq *"
334Flush addresses from the cache.
335.Va ifbr_name
336contains the name of the bridge device, and
337.Va ifbr_ifsflags
338should be set to
339.Dv IFBF_FLUSHALL
340to flush all addresses from the cache or
341.Dv IFBF_FLUSHDYN
342to flush only the dynamically learned addresses from the cache.
343.It Dv SIOCBRDGSCACHE Fa "struct ifbrparam *"
344Set the maximum address cache size for the bridge named in
345.Va ifbrp_name
346to
347.Va ifbrp_csize
348entries.
349.Pp
350The argument structure is as follows:
351.Bd -literal
352struct ifbrparam {
353	char		  ifbrp_name[IFNAMSIZ];
354	union {
355		u_int32_t ifbrpu_csize;	    /* cache size */
356		int	  ifbrpu_ctime;	    /* cache time */
357		u_int16_t ifbrpu_prio;	    /* bridge priority */
358		u_int8_t  ifbrpu_hellotime; /* hello time */
359		u_int8_t  ifbrpu_fwddelay;  /* fwd delay */
360		u_int8_t  ifbrpu_maxage;    /* max age */
361		u_int64_t ifbrpu_datapath;  /* datapath-id */
362		u_int32_t ifbrpu_maxgroup;  /* group size */
363	} ifbrp_ifbrpu;
364};
365#define	ifbrp_csize	ifbrp_ifbrpu.ifbrpu_csize
366#define	ifbrp_ctime	ifbrp_ifbrpu.ifbrpu_ctime
367#define	ifbrp_prio	ifbrp_ifbrpu.ifbrpu_prio
368#define	ifbrp_hellotime	ifbrp_ifbrpu.ifbrpu_hellotime
369#define	ifbrp_fwddelay	ifbrp_ifbrpu.ifbrpu_fwddelay
370#define	ifbrp_maxage	ifbrp_ifbrpu.ifbrpu_maxage
371#define	ifbrp_datapath  ifbrp_ifbrpu.ifbrpu_datapath
372#define	ifbrp_maxflow   ifbrp_ifbrpu.ifbrpu_csize
373#define	ifbrp_maxgroup  ifbrp_ifbrpu.ifbrpu_maxgroup
374.Ed
375.Pp
376Note that the
377.Va ifbrp_ctime , ifbrp_hellotime , ifbrp_fwddelay
378and
379.Va ifbrp_maxage
380fields are in seconds.
381.It Dv SIOCBRDGGCACHE Fa "struct ifbrparam *"
382Retrieve the maximum size of the address cache for the bridge
383.Va ifbrp_name .
384.It Dv SIOCBRDGSTO Fa "struct ifbrparam *"
385Set the time, in seconds, for how long addresses which have not been
386seen on the network (i.e., have not transmitted a packet) will remain in
387the cache to the value
388.Va ifbrp_ctime .
389If the time is set to zero, no aging is performed on the address cache.
390.It Dv SIOCBRDGGTO Fa "struct ifbrparam *"
391Retrieve the address cache expiration time (see above).
392.It Dv SIOCBRDGARL Fa "struct ifbrlreq *"
393Add an Ethernet address filtering rule to the bridge on a specific interface.
394.Va ifbr_name
395contains the name of the bridge device, and
396.Va ifbr_ifsname
397contains the name of the bridge member interface.
398.Pp
399Rules are applied in the order in which they were added to the bridge,
400and the first matching rule's action parameter determines the fate of
401the packet.
402The
403.Va ifbr_action
404field is one of
405.Dv BRL_ACTION_PASS
406or
407.Dv BRL_ACTION_BLOCK ,
408to pass or block matching frames, respectively.
409The
410.Va ifbr_flags
411field specifies whether the rule should match on input, output, or both
412by using the flags
413.Dv BRL_FLAG_IN
414and
415.Dv BRL_FLAG_OUT .
416At least one of these flags must be set.
417.Pp
418The
419.Va ifbr_flags
420field
421also specifies whether either (or both) of the source and destination
422addresses should be matched by using the
423.Dv BRL_FLAG_SRCVALID
424and
425.Dv BRL_FLAG_DSTVALID
426flags.
427The
428.Va ifbr_src
429field is the source address that triggers the rule (only considered if
430.Va ifbr_flags
431has the
432.Dv BRL_FLAG_SRCVALID
433bit set).
434The
435.Va ifbr_src
436field is the destination address that triggers the rule (only considered if
437.Va ifbr_flags
438has the
439.Dv BRL_FLAG_DSTVALID
440bit set).
441If neither bit is set, the rule matches all frames.
442.Pp
443The argument structure is as follows:
444.Bd -literal
445struct ifbrlreq {
446	char	 ifbr_name[IFNAMSIZ];	 /* bridge ifs name */
447	char	 ifbr_ifsname[IFNAMSIZ]; /* member ifs name */
448	u_int8_t ifbr_action;		 /* disposition */
449	u_int8_t ifbr_flags;		 /* flags */
450	struct ether_addr ifbr_src;	 /* source mac */
451	struct ether_addr ifbr_dst;	 /* destination mac */
452	char	 ifbr_tagname[PF_TAG_NAME_SIZE]; /* pf tagname */
453};
454#define	BRL_ACTION_BLOCK	0x01	 /* block frame */
455#define	BRL_ACTION_PASS		0x02	 /* pass frame */
456#define	BRL_FLAG_IN		0x08	 /* input rule */
457#define	BRL_FLAG_OUT		0x04	 /* output rule */
458#define	BRL_FLAG_SRCVALID	0x02	 /* src valid */
459#define	BRL_FLAG_DSTVALID	0x01	 /* dst valid */
460.Ed
461.It Dv SIOCBRDGFRL Fa "struct ifbrlreq *"
462Remove all filtering rules from a bridge interface member.
463.Va ifbr_name
464contains the name of the bridge device, and
465.Va ifbr_ifsname
466contains the name of the bridge member interface.
467.It Dv SIOCBRDGGRL Fa "struct ifbrlconf *"
468Retrieve all of the rules from the bridge,
469.Va ifbrl_name ,
470for the member interface,
471.Va ifbrl_ifsname .
472This request takes an
473.Vt ifbrlconf
474structure (see below) as a value-result parameter.
475The
476.Va ifbrl_len
477field should be initially set to the size of the buffer pointed to by
478.Va ifbrl_buf .
479On return, it will contain the length, in bytes, of the configuration list.
480.Pp
481Alternatively, if the
482.Va ifbrl_len
483passed in is set to 0,
484.Dv SIOCBRDGGRL
485will set it to the size that
486.Va ifbrl_buf
487needs to be to fit the entire configuration list, and will not fill in the other
488parameters.
489As with
490.Dv SIOCBRDGIFS ,
491this is useful for determining the exact size that
492.Va ifbrl_buf
493needs to be in advance.
494.Pp
495The argument structure is defined as follows:
496.Bd -literal
497struct ifbrlconf {
498	char	  ifbrl_name[IFNAMSIZ];	   /* bridge ifs name */
499	char	  ifbrl_ifsname[IFNAMSIZ]; /* member ifs name */
500	u_int32_t ifbrl_len;		   /* buffer size */
501	union {
502		caddr_t	ifbrlu_buf;
503		struct	ifbrlreq *ifbrlu_req;
504	} ifbrl_ifbrlu;
505#define	ifbrl_buf ifbrl_ifbrlu.ifbrlu_buf
506#define	ifbrl_req ifbrl_ifbrlu.ifbrlu_req
507};
508.Ed
509.It Dv SIOCBRDGGPRI Fa "struct ifbrparam *"
510Retrieve the Spanning Tree Protocol (STP) priority parameter of the bridge into
511the
512.Va ifbrp_prio
513field.
514.It Dv SIOCBRDGSPRI Fa "struct ifbrparam *"
515Set the STP priority parameter of the bridge to the value in
516.Va ifbrp_prio .
517.It Dv SIOCBRDGGHT Fa "struct ifbrparam *"
518Retrieve the STP hello time parameter, in seconds, of the bridge into the
519.Va ifbrp_hellotime
520field.
521.It Dv SIOCBRDGSHT Fa "struct ifbrparam *"
522Set the STP hello time parameter, in seconds, of the bridge to the value in
523.Va ifbrp_hellotime .
524The value in
525.Va ifbrp_hellotime
526cannot be zero.
527.It Dv SIOCBRDGGFD Fa "struct ifbrparam *"
528Retrieve the STP forward delay parameter, in seconds, of the bridge into the
529.Va ifbrp_fwddelay
530field.
531.It Dv SIOCBRDGSFD Fa "struct ifbrparam *"
532Set the STP forward delay parameter, in seconds, of the bridge to the value in
533.Va ifbrp_fwddelay .
534The value in
535.Va ifbrp_fwddelay
536cannot be zero.
537.It Dv SIOCBRDGGMA Fa "struct ifbrparam *"
538Retrieve the STP maximum age parameter, in seconds, of the bridge into the
539.Va ifbrp_maxage
540field.
541.It Dv SIOCBRDGSMA Fa "struct ifbrparam *"
542Set the STP maximum age parameter, in seconds, of the bridge to the value in
543.Va ifbrp_maxage .
544The value in
545.Va ifbrp_maxage
546cannot be zero.
547.It Dv SIOCBRDGSIFPRIO Fa "struct ifbreq *"
548Set the STP priority parameter of the interface named in
549.Va ifbr_ifsname
550to the value in
551.Va ifbr_priority .
552.It Dv SIOCBRDGSIFCOST Fa "struct ifbreq *"
553Set the STP cost parameter of the interface named in
554.Va ifbr_ifsname
555to the value in
556.Va ifbr_path_cost .
557The value in
558.Va ifbr_path_cost
559must be greater than or equal to one.
560.It Dv SIOCBRDGSIFPROT Fa "struct ifbreq *"
561Set the protection domain membership of the interface named in
562.Va ifbr_ifsname
563to the value in
564.Va ifbr_protected .
565.El
566.Sh ERRORS
567If the
568.Xr ioctl 2
569call fails,
570.Xr errno 2
571is set to one of the following values:
572.Bl -tag -width Er
573.It Bq Er ENOENT
574For an add request, this means that the named interface is not configured
575into the system.
576For a delete operation, it means that the named interface is not a member
577of the bridge.
578For an address cache deletion, the address was not found in the table.
579.It Bq Er ENOMEM
580Memory could not be allocated for an interface or cache entry
581to be added to the bridge.
582.It Bq Er EEXIST
583The named interface is already a member of the bridge.
584.It Bq Er EBUSY
585The named interface is already a member of another bridge.
586.It Bq Er EINVAL
587The named interface is not an Ethernet interface, or an invalid ioctl
588was performed on the bridge.
589.It Bq Er ENETDOWN
590Address cache operation (flush, add, or delete) on a bridge that is
591in the down state.
592.It Bq Er EPERM
593Super-user privilege is required to add and delete interfaces to and from
594bridges and to set the bridge interface flags.
595.It Bq Er EFAULT
596The buffer used in a
597.Dv SIOCBRDGIFS
598or
599.Dv SIOCBRDGRTS
600request points outside of the process's allocated address space.
601.It Bq Er ESRCH
602No such member interface in the bridge.
603.El
604.Sh NOTES
605Bridged packets pass through
606.Xr pf 4
607filters once as input on the receiving interface and once
608as output on all interfaces on which they are forwarded.
609In order to pass through the bridge packets must pass
610any
611.Ar in
612rules on the input and any
613.Ar out
614rules on the output interface.
615Packets may be blocked either entering or leaving the bridge.
616.Pp
617Return packets generated by pf itself are not routed using the
618kernel routing table.
619Instead, pf will send these replies back to the same Ethernet
620address that the original packet came from.
621This applies to rules with
622.Ic return ,
623.Ic return-rst ,
624.Ic return-icmp ,
625.Ic return-icmp6 ,
626or
627.Ic synproxy
628defined.
629At the moment, only
630.Ic return-rst
631on IPv4 is implemented and the other packet generating rules
632are unsupported.
633.Pp
634If an IP packet is too large for the outgoing interface, the bridge
635will perform IP fragmentation.
636This can happen when bridge members
637have different MTUs or when IP fragments are reassembled by pf.
638Non-IP packets which are too large for the outgoing interface will be
639dropped.
640.Pp
641If the
642.Dv IFF_LINK2
643flag is set on the
644.Nm
645interface, the bridge will also perform transparent
646.Xr ipsec 4
647processing on the packets (encrypt or decrypt them), according to the
648policies set with the
649.Xr ipsecctl 8
650command by the administrator.
651If appropriate security associations (SAs) do not exist, any key
652management daemons such as
653.Xr isakmpd 8
654that are running on the bridge will be invoked to establish the
655necessary SAs.
656These daemons have to be configured as if they were running on the
657host whose traffic they are protecting (i.e., they need to have the
658appropriate authentication and authorization material, such as keys
659and certificates, to impersonate the protected host(s)).
660.Sh SEE ALSO
661.Xr errno 2 ,
662.Xr ioctl 2 ,
663.Xr arp 4 ,
664.Xr etherip 4 ,
665.Xr ip 4 ,
666.Xr ip6 4 ,
667.Xr ipsec 4 ,
668.Xr netintro 4 ,
669.Xr pf 4 ,
670.Xr switch 4 ,
671.Xr vether 4 ,
672.Xr hostname.if 5 ,
673.Xr ifconfig 8 ,
674.Xr ipsecctl 8 ,
675.Xr isakmpd 8 ,
676.Xr netstart 8
677.Sh HISTORY
678The
679.Nm
680kernel interface first appeared in
681.Ox 2.5 .
682.Sh AUTHORS
683The
684.Nm
685kernel interface was written by
686.An Jason L. Wright Aq Mt jason@thought.net
687as part of an undergraduate independent study at the
688University of North Carolina at Greensboro.
689.Pp
690Support for rapid spanning tree reconfigurations (RSTP) was added by
691.An Andrew Thompson Aq Mt thompsa@freebsd.org
692and ported to
693.Ox
694by
695.An Reyk Floeter Aq Mt reyk@openbsd.org .
696.Sh BUGS
697There are some rather special network interface chipsets which will
698not work in a bridge configuration.
699Some chipsets have serious flaws when running in promiscuous mode, like the
700TI ThunderLAN (see
701.Xr tl 4 ) ,
702which receives its own transmissions (this renders the address learning
703cache useless).
704Most other chipsets work fine though.
705