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