1.\" $OpenBSD: bridge.4,v 1.80 2020/08/27 21:06:34 kn 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 27 2020 $ 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 151and 152.Xr tpmr 4 153as well. 154.Bl -tag -width Ds 155.It Dv SIOCBRDGIFS Fa "struct ifbifconf *" 156Retrieve member interface list from a bridge. 157This request takes an 158.Vt ifbifconf 159structure (see below) as a value-result parameter. 160The 161.Va ifbic_len 162field should be initially set to the size of the buffer 163pointed to by 164.Va ifbic_buf . 165On return it will contain the length, in bytes, of the configuration 166list. 167.Pp 168Alternatively, if the 169.Va ifbic_len 170passed in is set to 0, 171.Dv SIOCBRDGIFS 172will set 173.Va ifbic_len 174to the size that 175.Va ifbic_buf 176needs to be to fit the entire configuration list, 177and will not fill in the other parameters. 178This is useful for determining the exact size that 179.Va ifbic_buf 180needs to be in advance. 181.Pp 182The argument structure is defined as follows: 183.Bd -literal 184struct ifbreq { 185 char ifbr_name[IFNAMSIZ]; /* bridge ifs name */ 186 char ifbr_ifsname[IFNAMSIZ];/* member ifs name */ 187 u_int32_t ifbr_ifsflags; /* member ifs flags */ 188 u_int8_t ifbr_state; /* member stp state */ 189 u_int8_t ifbr_priority; /* member stp priority */ 190 u_int32_t ifbr_portno; /* member port number */ 191 u_int32_t ifbr_path_cost; /* member stp path cost */ 192}; 193 194/* ifbr_ifsflags flags about interfaces */ 195#define IFBIF_LEARNING 0x0001 /* ifs can learn */ 196#define IFBIF_DISCOVER 0x0002 /* sends packets w/unknown dst */ 197#define IFBIF_BLOCKNONIP 0x0004 /* ifs blocks non-IP/ARP in/out */ 198#define IFBIF_STP 0x0008 /* participate in spanning tree*/ 199#define IFBIF_SPAN 0x0100 /* ifs is a span port (ro) */ 200#define IFBIF_RO_MASK 0xff00 /* read only bits */ 201 202struct ifbifconf { 203 char ifbic_name[IFNAMSIZ]; /* bridge ifs name */ 204 u_int32_t ifbic_len; /* buffer size */ 205 union { 206 caddr_t ifbicu_buf; 207 struct ifbreq *ifbicu_req; 208 } ifbic_ifbicu; 209#define ifbic_buf ifbic_ifbicu.ifbicu_buf 210#define ifbic_req ifbic_ifbicu.ifbicu_req 211}; 212.Ed 213.It Dv SIOCBRDGADD Fa "struct ifbreq *" 214Add the interface named in 215.Va ifbr_ifsname 216to the bridge named in 217.Va ifbr_name . 218.It Dv SIOCBRDGDEL Fa "struct ifbreq *" 219Delete the interface named in 220.Va ifbr_ifsname 221from the bridge named in 222.Va ifbr_name . 223.It Dv SIOCBRDGADDS Fa "struct ifbreq *" 224Add the interface named in 225.Va ifbr_ifsname 226as a span port to the bridge named in 227.Va ifbr_name . 228.It Dv SIOCBRDGDELS Fa "struct ifbreq *" 229Delete the interface named in 230.Va ifbr_ifsname 231from the list of span ports of the bridge named in 232.Va ifbr_name . 233.It Dv SIOCBRDGSIFFLGS Fa "struct ifbreq *" 234Set the bridge member interface flags for the interface named in 235.Va ifbr_ifsname 236attached to the bridge 237.Va ifbr_name . 238If the flag 239.Dv IFBIF_LEARNING 240is set on an interface, source addresses from frames received on the 241interface are recorded in the address cache. 242If the flag 243.Dv IFBIF_DISCOVER 244is set, the interface will receive packets destined for unknown 245destinations, otherwise a frame that has a destination not found 246in the address cache is not forwarded to this interface. 247The default for newly added interfaces has both flags set. 248If the flag 249.Dv IFBIF_BLOCKNONIP 250is set, only 251.Xr ip 4 , 252.Xr ip6 4 , 253.Xr arp 4 , 254and 255Reverse ARP packets will be bridged from and to the interface. 256.It Dv SIOCBRDGGIFFLGS Fa "struct ifbreq *" 257Retrieve the bridge member interface flags for the interface named in 258.Va ifbr_ifsname 259attached to the bridge 260.Va ifbr_name . 261.It Dv SIOCBRDGRTS Fa "struct ifbaconf *" 262Retrieve the address cache of the bridge named in 263.Va ifbac_name . 264This request takes an 265.Vt ifbaconf 266structure (see below) as a value-result parameter. 267The 268.Va ifbac_len 269field should be initially set to the size of the buffer pointed to by 270.Va ifbac_buf . 271On return, it will contain the length, in bytes, of the configuration list. 272.Pp 273Alternatively, if the 274.Va ifbac_len 275passed in is set to 0, 276.Dv SIOCBRDGRTS 277will set it to the size that 278.Va ifbac_buf 279needs to be to fit the entire configuration list, and will not fill in the other 280parameters. 281As with 282.Dv SIOCBRDGIFS , 283this is useful for determining the exact size that 284.Va ifbac_buf 285needs to be in advance. 286.Pp 287The argument structure is defined as follows: 288.Bd -literal 289struct ifbareq { 290 char ifba_name[IFNAMSIZ]; /* bridge name */ 291 char ifba_ifsname[IFNAMSIZ];/* destination ifs */ 292 u_int8_t ifba_age; /* address age */ 293 u_int8_t ifba_flags; /* address flags */ 294 struct ether_addr ifba_dst; /* destination addr */ 295}; 296 297#define IFBAF_TYPEMASK 0x03 /* address type mask */ 298#define IFBAF_DYNAMIC 0x00 /* dynamically learned */ 299#define IFBAF_STATIC 0x01 /* static address */ 300 301struct ifbaconf { 302 char ifbac_name[IFNAMSIZ]; /* bridge ifs name */ 303 u_int32_t ifbac_len; /* buffer size */ 304 union { 305 caddr_t ifbacu_buf; /* buffer */ 306 struct ifbareq *ifbacu_req; /* request pointer */ 307 } ifbac_ifbacu; 308#define ifbac_buf ifbac_ifbacu.ifbacu_buf 309#define ifbac_req ifbac_ifbacu.ifbacu_req 310}; 311.Ed 312.Pp 313Address cache entries with the type set to 314.Dv IFBAF_DYNAMIC 315in 316.Va ifba_flags 317are entries learned by the bridge. 318Entries with the type set to 319.Dv IFBAF_STATIC 320are manually added entries. 321.It Dv SIOCBRDGSADDR Fa "struct ifbareq *" 322Add an entry, manually, to the address cache for the bridge named in 323.Va ifba_name . 324The address and its associated interface and flags are set in the 325.Va ifba_dst , 326.Va ifba_ifsname , 327and 328.Va ifba_flags 329fields, respectively. 330.It Dv SIOCBRDGDADDR Fa "struct ifbareq *" 331Delete an entry from the address cache of the bridge named in 332.Va ifba_name . 333Entries are deleted strictly based on the address field 334.Va ifba_dst . 335.It Dv SIOCBRDGFLUSH Fa "struct ifbreq *" 336Flush addresses from the cache. 337.Va ifbr_name 338contains the name of the bridge device, and 339.Va ifbr_ifsflags 340should be set to 341.Dv IFBF_FLUSHALL 342to flush all addresses from the cache or 343.Dv IFBF_FLUSHDYN 344to flush only the dynamically learned addresses from the cache. 345.It Dv SIOCBRDGSCACHE Fa "struct ifbrparam *" 346Set the maximum address cache size for the bridge named in 347.Va ifbrp_name 348to 349.Va ifbrp_csize 350entries. 351.Pp 352The argument structure is as follows: 353.Bd -literal 354struct ifbrparam { 355 char ifbrp_name[IFNAMSIZ]; 356 union { 357 u_int32_t ifbrpu_csize; /* cache size */ 358 int ifbrpu_ctime; /* cache time */ 359 u_int16_t ifbrpu_prio; /* bridge priority */ 360 u_int8_t ifbrpu_hellotime; /* hello time */ 361 u_int8_t ifbrpu_fwddelay; /* fwd delay */ 362 u_int8_t ifbrpu_maxage; /* max age */ 363 u_int64_t ifbrpu_datapath; /* datapath-id */ 364 u_int32_t ifbrpu_maxgroup; /* group size */ 365 } ifbrp_ifbrpu; 366}; 367#define ifbrp_csize ifbrp_ifbrpu.ifbrpu_csize 368#define ifbrp_ctime ifbrp_ifbrpu.ifbrpu_ctime 369#define ifbrp_prio ifbrp_ifbrpu.ifbrpu_prio 370#define ifbrp_hellotime ifbrp_ifbrpu.ifbrpu_hellotime 371#define ifbrp_fwddelay ifbrp_ifbrpu.ifbrpu_fwddelay 372#define ifbrp_maxage ifbrp_ifbrpu.ifbrpu_maxage 373#define ifbrp_datapath ifbrp_ifbrpu.ifbrpu_datapath 374#define ifbrp_maxflow ifbrp_ifbrpu.ifbrpu_csize 375#define ifbrp_maxgroup ifbrp_ifbrpu.ifbrpu_maxgroup 376.Ed 377.Pp 378Note that the 379.Va ifbrp_ctime , ifbrp_hellotime , ifbrp_fwddelay 380and 381.Va ifbrp_maxage 382fields are in seconds. 383.It Dv SIOCBRDGGCACHE Fa "struct ifbrparam *" 384Retrieve the maximum size of the address cache for the bridge 385.Va ifbrp_name . 386.It Dv SIOCBRDGSTO Fa "struct ifbrparam *" 387Set the time, in seconds, for how long addresses which have not been 388seen on the network (i.e., have not transmitted a packet) will remain in 389the cache to the value 390.Va ifbrp_ctime . 391If the time is set to zero, no aging is performed on the address cache. 392.It Dv SIOCBRDGGTO Fa "struct ifbrparam *" 393Retrieve the address cache expiration time (see above). 394.It Dv SIOCBRDGARL Fa "struct ifbrlreq *" 395Add an Ethernet address filtering rule to the bridge on a specific interface. 396.Va ifbr_name 397contains the name of the bridge device, and 398.Va ifbr_ifsname 399contains the name of the bridge member interface. 400.Pp 401Rules are applied in the order in which they were added to the bridge, 402and the first matching rule's action parameter determines the fate of 403the packet. 404The 405.Va ifbr_action 406field is one of 407.Dv BRL_ACTION_PASS 408or 409.Dv BRL_ACTION_BLOCK , 410to pass or block matching frames, respectively. 411The 412.Va ifbr_flags 413field specifies whether the rule should match on input, output, or both 414by using the flags 415.Dv BRL_FLAG_IN 416and 417.Dv BRL_FLAG_OUT . 418At least one of these flags must be set. 419.Pp 420The 421.Va ifbr_flags 422field 423also specifies whether either (or both) of the source and destination 424addresses should be matched by using the 425.Dv BRL_FLAG_SRCVALID 426and 427.Dv BRL_FLAG_DSTVALID 428flags. 429The 430.Va ifbr_src 431field is the source address that triggers the rule (only considered if 432.Va ifbr_flags 433has the 434.Dv BRL_FLAG_SRCVALID 435bit set). 436The 437.Va ifbr_src 438field is the destination address that triggers the rule (only considered if 439.Va ifbr_flags 440has the 441.Dv BRL_FLAG_DSTVALID 442bit set). 443If neither bit is set, the rule matches all frames. 444.Pp 445The argument structure is as follows: 446.Bd -literal 447struct ifbrlreq { 448 char ifbr_name[IFNAMSIZ]; /* bridge ifs name */ 449 char ifbr_ifsname[IFNAMSIZ]; /* member ifs name */ 450 u_int8_t ifbr_action; /* disposition */ 451 u_int8_t ifbr_flags; /* flags */ 452 struct ether_addr ifbr_src; /* source mac */ 453 struct ether_addr ifbr_dst; /* destination mac */ 454 char ifbr_tagname[PF_TAG_NAME_SIZE]; /* pf tagname */ 455}; 456#define BRL_ACTION_BLOCK 0x01 /* block frame */ 457#define BRL_ACTION_PASS 0x02 /* pass frame */ 458#define BRL_FLAG_IN 0x08 /* input rule */ 459#define BRL_FLAG_OUT 0x04 /* output rule */ 460#define BRL_FLAG_SRCVALID 0x02 /* src valid */ 461#define BRL_FLAG_DSTVALID 0x01 /* dst valid */ 462.Ed 463.It Dv SIOCBRDGFRL Fa "struct ifbrlreq *" 464Remove all filtering rules from a bridge interface member. 465.Va ifbr_name 466contains the name of the bridge device, and 467.Va ifbr_ifsname 468contains the name of the bridge member interface. 469.It Dv SIOCBRDGGRL Fa "struct ifbrlconf *" 470Retrieve all of the rules from the bridge, 471.Va ifbrl_name , 472for the member interface, 473.Va ifbrl_ifsname . 474This request takes an 475.Vt ifbrlconf 476structure (see below) as a value-result parameter. 477The 478.Va ifbrl_len 479field should be initially set to the size of the buffer pointed to by 480.Va ifbrl_buf . 481On return, it will contain the length, in bytes, of the configuration list. 482.Pp 483Alternatively, if the 484.Va ifbrl_len 485passed in is set to 0, 486.Dv SIOCBRDGGRL 487will set it to the size that 488.Va ifbrl_buf 489needs to be to fit the entire configuration list, and will not fill in the other 490parameters. 491As with 492.Dv SIOCBRDGIFS , 493this is useful for determining the exact size that 494.Va ifbrl_buf 495needs to be in advance. 496.Pp 497The argument structure is defined as follows: 498.Bd -literal 499struct ifbrlconf { 500 char ifbrl_name[IFNAMSIZ]; /* bridge ifs name */ 501 char ifbrl_ifsname[IFNAMSIZ]; /* member ifs name */ 502 u_int32_t ifbrl_len; /* buffer size */ 503 union { 504 caddr_t ifbrlu_buf; 505 struct ifbrlreq *ifbrlu_req; 506 } ifbrl_ifbrlu; 507#define ifbrl_buf ifbrl_ifbrlu.ifbrlu_buf 508#define ifbrl_req ifbrl_ifbrlu.ifbrlu_req 509}; 510.Ed 511.It Dv SIOCBRDGGPRI Fa "struct ifbrparam *" 512Retrieve the Spanning Tree Protocol (STP) priority parameter of the bridge into 513the 514.Va ifbrp_prio 515field. 516.It Dv SIOCBRDGSPRI Fa "struct ifbrparam *" 517Set the STP priority parameter of the bridge to the value in 518.Va ifbrp_prio . 519.It Dv SIOCBRDGGHT Fa "struct ifbrparam *" 520Retrieve the STP hello time parameter, in seconds, of the bridge into the 521.Va ifbrp_hellotime 522field. 523.It Dv SIOCBRDGSHT Fa "struct ifbrparam *" 524Set the STP hello time parameter, in seconds, of the bridge to the value in 525.Va ifbrp_hellotime . 526The value in 527.Va ifbrp_hellotime 528cannot be zero. 529.It Dv SIOCBRDGGFD Fa "struct ifbrparam *" 530Retrieve the STP forward delay parameter, in seconds, of the bridge into the 531.Va ifbrp_fwddelay 532field. 533.It Dv SIOCBRDGSFD Fa "struct ifbrparam *" 534Set the STP forward delay parameter, in seconds, of the bridge to the value in 535.Va ifbrp_fwddelay . 536The value in 537.Va ifbrp_fwddelay 538cannot be zero. 539.It Dv SIOCBRDGGMA Fa "struct ifbrparam *" 540Retrieve the STP maximum age parameter, in seconds, of the bridge into the 541.Va ifbrp_maxage 542field. 543.It Dv SIOCBRDGSMA Fa "struct ifbrparam *" 544Set the STP maximum age parameter, in seconds, of the bridge to the value in 545.Va ifbrp_maxage . 546The value in 547.Va ifbrp_maxage 548cannot be zero. 549.It Dv SIOCBRDGSIFPRIO Fa "struct ifbreq *" 550Set the STP priority parameter of the interface named in 551.Va ifbr_ifsname 552to the value in 553.Va ifbr_priority . 554.It Dv SIOCBRDGSIFCOST Fa "struct ifbreq *" 555Set the STP cost parameter of the interface named in 556.Va ifbr_ifsname 557to the value in 558.Va ifbr_path_cost . 559The value in 560.Va ifbr_path_cost 561must be greater than or equal to one. 562.It Dv SIOCBRDGSIFPROT Fa "struct ifbreq *" 563Set the protection domain membership of the interface named in 564.Va ifbr_ifsname 565to the value in 566.Va ifbr_protected . 567.El 568.Sh ERRORS 569If the 570.Xr ioctl 2 571call fails, 572.Xr errno 2 573is set to one of the following values: 574.Bl -tag -width Er 575.It Bq Er ENOENT 576For an add request, this means that the named interface is not configured 577into the system. 578For a delete operation, it means that the named interface is not a member 579of the bridge. 580For an address cache deletion, the address was not found in the table. 581.It Bq Er ENOMEM 582Memory could not be allocated for an interface or cache entry 583to be added to the bridge. 584.It Bq Er EEXIST 585The named interface is already a member of the bridge. 586.It Bq Er EBUSY 587The named interface is already a member of another bridge. 588.It Bq Er EINVAL 589The named interface is not an Ethernet interface, or an invalid ioctl 590was performed on the bridge. 591.It Bq Er ENETDOWN 592Address cache operation (flush, add, or delete) on a bridge that is 593in the down state. 594.It Bq Er EPERM 595Super-user privilege is required to add and delete interfaces to and from 596bridges and to set the bridge interface flags. 597.It Bq Er EFAULT 598The buffer used in a 599.Dv SIOCBRDGIFS 600or 601.Dv SIOCBRDGRTS 602request points outside of the process's allocated address space. 603.It Bq Er ESRCH 604No such member interface in the bridge. 605.El 606.Sh NOTES 607Bridged packets pass through 608.Xr pf 4 609filters once as input on the receiving interface and once 610as output on all interfaces on which they are forwarded. 611In order to pass through the bridge packets must pass 612any 613.Ar in 614rules on the input and any 615.Ar out 616rules on the output interface. 617Packets may be blocked either entering or leaving the bridge. 618.Pp 619Return packets generated by pf itself are not routed using the 620kernel routing table. 621Instead, pf will send these replies back to the same Ethernet 622address that the original packet came from. 623This applies to rules with 624.Ic return , 625.Ic return-rst , 626.Ic return-icmp , 627.Ic return-icmp6 , 628or 629.Ic synproxy 630defined. 631At the moment, only 632.Ic return-rst 633on IPv4 is implemented and the other packet generating rules 634are unsupported. 635.Pp 636If an IP packet is too large for the outgoing interface, the bridge 637will perform IP fragmentation. 638This can happen when bridge members 639have different MTUs or when IP fragments are reassembled by pf. 640Non-IP packets which are too large for the outgoing interface will be 641dropped. 642.Pp 643If the 644.Dv IFF_LINK2 645flag is set on the 646.Nm 647interface, the bridge will also perform transparent 648.Xr ipsec 4 649processing on the packets (encrypt or decrypt them), according to the 650policies set with the 651.Xr ipsecctl 8 652command by the administrator. 653If appropriate security associations (SAs) do not exist, any key 654management daemons such as 655.Xr isakmpd 8 656that are running on the bridge will be invoked to establish the 657necessary SAs. 658These daemons have to be configured as if they were running on the 659host whose traffic they are protecting (i.e., they need to have the 660appropriate authentication and authorization material, such as keys 661and certificates, to impersonate the protected host(s)). 662.Sh SEE ALSO 663.Xr errno 2 , 664.Xr ioctl 2 , 665.Xr arp 4 , 666.Xr etherip 4 , 667.Xr ip 4 , 668.Xr ip6 4 , 669.Xr ipsec 4 , 670.Xr netintro 4 , 671.Xr pf 4 , 672.Xr switch 4 , 673.Xr tpmr 4 , 674.Xr vether 4 , 675.Xr hostname.if 5 , 676.Xr ifconfig 8 , 677.Xr ipsecctl 8 , 678.Xr isakmpd 8 , 679.Xr netstart 8 680.Sh HISTORY 681The 682.Nm 683kernel interface first appeared in 684.Ox 2.5 . 685.Sh AUTHORS 686The 687.Nm 688kernel interface was written by 689.An Jason L. Wright Aq Mt jason@thought.net 690as part of an undergraduate independent study at the 691University of North Carolina at Greensboro. 692.Pp 693Support for rapid spanning tree reconfigurations (RSTP) was added by 694.An Andrew Thompson Aq Mt thompsa@freebsd.org 695and ported to 696.Ox 697by 698.An Reyk Floeter Aq Mt reyk@openbsd.org . 699.Sh BUGS 700There are some rather special network interface chipsets which will 701not work in a bridge configuration. 702Some chipsets have serious flaws when running in promiscuous mode, like the 703TI ThunderLAN (see 704.Xr tl 4 ) , 705which receives its own transmissions (this renders the address learning 706cache useless). 707Most other chipsets work fine though. 708