diff options
Diffstat (limited to 'static/freebsd/man4/bridge.4 3.html')
| -rw-r--r-- | static/freebsd/man4/bridge.4 3.html | 523 |
1 files changed, 523 insertions, 0 deletions
diff --git a/static/freebsd/man4/bridge.4 3.html b/static/freebsd/man4/bridge.4 3.html new file mode 100644 index 00000000..60d81a4a --- /dev/null +++ b/static/freebsd/man4/bridge.4 3.html @@ -0,0 +1,523 @@ +<table class="head"> + <tr> + <td class="head-ltitle">IF_BRIDGE(4)</td> + <td class="head-vol">Device Drivers Manual</td> + <td class="head-rtitle">IF_BRIDGE(4)</td> + </tr> +</table> +<div class="manual-text"> +<section class="Sh"> +<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> +<p class="Pp"><code class="Nm">if_bridge</code> — + <span class="Nd">network bridge device</span></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1> +<p class="Pp">To compile this driver into the kernel, place the following line + in your kernel configuration file:</p> +<div class="Bd Pp Bd-indent"><code class="Cd">device if_bridge</code></div> +<p class="Pp">Alternatively, to load the driver as a module at boot time, place + the following lines in <a class="Xr">loader.conf(5)</a>:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>if_bridge_load="YES" +bridgestp_load="YES"</pre> +</div> +</section> +<section class="Sh"> +<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> +<p class="Pp">The <code class="Nm">if_bridge</code> driver creates a logical + link between two or more IEEE 802 networks that use the same (or + “similar enough”) framing format. For example, it is possible + to bridge Ethernet and 802.11 networks together, but it is not possible to + bridge Ethernet and Token Ring together.</p> +<p class="Pp">Each <code class="Nm">if_bridge</code> interface is created at + runtime using interface cloning. This is most easily done with the + <a class="Xr">ifconfig(8)</a> <code class="Cm">create</code> command or + using the <var class="Va">cloned_interfaces</var> variable in + <a class="Xr">rc.conf(5)</a>.</p> +<p class="Pp" id="only">When it is created, the + <code class="Nm">if_bridge</code> interface gets assigned a link (MAC) + address in the range of universally administered addresses reserved for the + FreeBSD Foundation by hashing the host UUID, jail name, and the interface + name. If this fails, a random, locally administered address is generated + instead. This address is guaranteed to be unique + <a class="permalink" href="#only"><i class="Em">only</i></a> across all + <code class="Nm">if_bridge</code> interfaces on the local machine. Thus you + can theoretically have two bridges on different machines with the same link + addresses. The address can be changed by assigning the desired link address + using <a class="Xr">ifconfig(8)</a>.</p> +<p class="Pp">If <a class="Xr">sysctl(8)</a> node + <var class="Va">net.link.bridge.inherit_mac</var> has a non-zero value, the + newly created bridge will inherit the MAC address from its first member + instead of choosing a random link-level address. This will provide more + predictable bridge MAC addresses without any additional configuration, but + currently this feature is known to break some L2 protocols, for example + PPPoE that is provided by <a class="Xr">ng_pppoe(4)</a> and + <a class="Xr">ppp(8)</a>. Currently this feature is considered as + experimental and is turned off by default.</p> +<p class="Pp">A bridge can be used to provide several services, such as a simple + 802.11-to-Ethernet bridge for wireless hosts, or traffic isolation.</p> +<p class="Pp">A bridge works like a switch, forwarding traffic from one + interface to another. Multicast and broadcast packets are always forwarded + to all interfaces that are part of the bridge. For unicast traffic, the + bridge learns which MAC addresses are associated with which interfaces and + will forward the traffic selectively.</p> +<p class="Pp">By default the bridge logs MAC address port flapping to + <a class="Xr">syslog(3)</a>. This behavior can be disabled by setting the + <a class="Xr">sysctl(8)</a> variable + <var class="Va">net.link.bridge.log_mac_flap</var> to + <code class="Li">0</code>.</p> +<p class="Pp">All the bridged member interfaces need to be up in order to pass + network traffic. These can be enabled using <a class="Xr">ifconfig(8)</a> or + <var class="Va">ifconfig_</var>⟨<var class="Ar">interface</var>⟩<code class="Li">="up"</code> + in <a class="Xr">rc.conf(5)</a>.</p> +<p class="Pp">The MTU of the first member interface to be added is used as the + bridge MTU. All additional members will have their MTU changed to match. If + the MTU of a bridge is changed after its creation, the MTU of all member + interfaces is also changed to match.</p> +<p class="Pp">The TOE, TSO, TXCSUM and TXCSUM6 capabilities on all interfaces + added to the bridge are disabled if any of the interfaces do not + support/enable them. The LRO capability is always disabled. All the + capabilities are restored when the interface is removed from the bridge. + Changing capabilities at run-time may cause NIC reinit and a link flap.</p> +<p class="Pp">The bridge supports “monitor mode”, where the + packets are discarded after <a class="Xr">bpf(4)</a> processing, and are not + processed or forwarded further. This can be used to multiplex the input of + two or more interfaces into a single <a class="Xr">bpf(4)</a> stream. This + is useful for reconstructing the traffic for network taps that transmit the + RX/TX signals out through two separate interfaces.</p> +<p class="Pp">To allow the host to communicate with bridge members, IP addresses + should be assigned to the <code class="Nm">if_bridge</code> interface + itself, not to the bridge's member interfaces. Attempting to assign an IP + address to a bridge member interface, or add a member interface with an + assigned IP address to a bridge, will return an + <code class="Dv">EINVAL</code> (“Invalid argument”) error. For + compatibility with older releases where this was permitted, setting the + <a class="Xr">sysctl(8)</a> variable + <var class="Va">net.link.bridge.member_ifaddrs</var> to 1 will permit this + configuration. This sysctl variable will be removed in + <span class="Ux">FreeBSD 16.0.</span></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="IPV6_SUPPORT"><a class="permalink" href="#IPV6_SUPPORT">IPV6 + SUPPORT</a></h1> +<p class="Pp"><code class="Nm">if_bridge</code> supports the + <code class="Li">AF_INET6</code> address family on bridge interfaces. The + following <a class="Xr">rc.conf(5)</a> variable configures an IPv6 + link-local address on <code class="Li">bridge0</code> interface:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig_bridge0_ipv6="inet6 auto_linklocal"</pre> +</div> +<p class="Pp">However, the <code class="Li">AF_INET6</code> address family has a + concept of scope zone. Bridging multiple interfaces changes the zone + configuration because multiple links are merged to each other and form a new + single link while the member interfaces still work individually. This means + each member interface still has a separate link-local scope zone and the + <code class="Nm">if_bridge</code> interface has another single, aggregated + link-local scope zone at the same time. This situation is clearly against + the description "zones of the same scope cannot overlap" in + Section 5, RFC 4007. Although it works in most cases, it can cause some + counterintuitive or undesirable behavior in some edge cases when both, the + <code class="Nm">if_bridge</code> interface and one of the member + interfaces, have an IPv6 address and applications use both of them.</p> +<p class="Pp">To prevent this situation, <code class="Nm">if_bridge</code> + checks whether a link-local scoped IPv6 address is configured on a member + interface to be added and the <code class="Nm">if_bridge</code> interface. + When the <code class="Nm">if_bridge</code> interface has IPv6 addresses, + IPv6 addresses on the member interface will be automatically removed before + the interface is added.</p> +<p class="Pp">This behavior can be disabled by setting + <a class="Xr">sysctl(8)</a> variable + <var class="Va">net.link.bridge.allow_llz_overlap</var> to + <code class="Li">1</code>.</p> +<p class="Pp">Note that <code class="Li">ACCEPT_RTADV</code> and + <code class="Li">AUTO_LINKLOCAL</code> interface flags are not enabled by + default on <code class="Nm">if_bridge</code> interfaces even when + <var class="Va">net.inet6.ip6.accept_rtadv</var> and/or + <var class="Va">net.inet6.ip6.auto_linklocal</var> is set to + <code class="Li">1</code>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="SPANNING_TREE"><a class="permalink" href="#SPANNING_TREE">SPANNING + TREE</a></h1> +<p class="Pp">The <code class="Nm">if_bridge</code> driver implements the Rapid + Spanning Tree Protocol (RSTP or 802.1w) with backwards compatibility with + the legacy Spanning Tree Protocol (STP). Spanning Tree is used to detect and + remove loops in a network topology.</p> +<p class="Pp">RSTP provides faster spanning tree convergence than legacy STP, + the protocol will exchange information with neighbouring switches to quickly + transition to forwarding without creating loops.</p> +<p class="Pp">The code will default to RSTP mode but will downgrade any port + connected to a legacy STP network so is fully backward compatible. A bridge + can be forced to operate in STP mode without rapid state transitions via the + <var class="Va">proto</var> command in <a class="Xr">ifconfig(8)</a>.</p> +<p class="Pp">The bridge can log STP port changes to <a class="Xr">syslog(3)</a> + by setting the <var class="Va">net.link.bridge.log_stp</var> node using + <a class="Xr">sysctl(8)</a>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="VLAN_SUPPORT"><a class="permalink" href="#VLAN_SUPPORT">VLAN + SUPPORT</a></h1> +<p class="Pp">Virtual LANs (VLANs), defined in the IEEE 802.1Q standard, allow + traffic on a bridge to be segregated into separate logical networks which + cannot communicate with each other. For example, two interfaces in VLAN 10 + would be able to communicate with each other, but not with another interface + in VLAN 20.</p> +<p class="Pp">Each VLAN is identified by a number between 1 and 4094 inclusive. + By default, all traffic on the bridge is assigned to "VLAN 0", a + pseudo-VLAN used for historical compatibility. When VLANs are in use on a + bridge, it is recommended to explicitly assign all traffic to a VLAN rather + than using VLAN 0.</p> +<p class="Pp">The bridge implements Independent VLAN Learning (IVL), meaning + that host addresses are learned separately for each VLAN, and the same host + address may exist on several different ports in different VLANs.</p> +<p class="Pp">If a <a class="Xr">vlan(4)</a> interface is configured on an + interface which is also an <code class="Nm">if_bridge</code> member + interface, all tagged frames will be processed by the + <a class="Xr">vlan(4)</a> interface and will not be visible to the bridge. + This configuration is not recommended and may be unsupported in a future + release.</p> +<section class="Ss"> +<h2 class="Ss" id="Tagged_and_untagged_traffic"><a class="permalink" href="#Tagged_and_untagged_traffic">Tagged + and untagged traffic</a></h2> +<p class="Pp">Incoming frames on a member interface may be either tagged or + untagged. Tagged frames contain an 802.1Q header indicating which VLAN the + frame belongs to, while untagged frames do not. When a tagged frame is + received, the frame is automatically assigned to the VLAN in the tag + (subject to any configured VLAN access list), while untagged frames are + assigned to the interface's configured Port VLAN ID (PVID), or to VLAN 0 if + no PVID is configured.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Assigning_interfaces_to_VLANs"><a class="permalink" href="#Assigning_interfaces_to_VLANs">Assigning + interfaces to VLANs</a></h2> +<p class="Pp">An interface's PVID may be configured using the + <a class="Xr">ifconfig(8)</a> <code class="Cm">ifuntagged</code> + command:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig bridge0 ifuntagged ix0 10</pre> +</div> +<p class="Pp">Or by using the <code class="Cm">untagged</code> option to + <code class="Cm">addm</code>:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig bridge0 addm ix0 untagged 10</pre> +</div> +<p class="Pp">This will assign all untagged traffic received on the interface to + the specified VLAN, and any traffic transmitted on the interface in this + VLAN will have its VLAN tag (if present) removed. Conversely, any traffic + transmitted on the interface in a different VLAN will have a tag added, to + allow the remote system to assign the traffic to the appropriate VLAN.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Host_communication_in_a_VLAN"><a class="permalink" href="#Host_communication_in_a_VLAN">Host + communication in a VLAN</a></h2> +<p class="Pp">Sometimes it is useful to allow the host itself to communicate in + a VLAN, for example to provide routing to other hosts in the VLAN. To do + this, create a <a class="Xr">vlan(4)</a> interface on top of the + <code class="Nm">if_bridge</code> interface with the appropriate VLAN tag. + For example, to allow the host to communicate in VLAN 10:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig bridge0.10 create inet6 2001:db8::1/64</pre> +</div> +</section> +<section class="Ss"> +<h2 class="Ss" id="Configuring_the_VLAN_access_list_(VLAN_filtering)"><a class="permalink" href="#Configuring_the_VLAN_access_list_(VLAN_filtering)">Configuring + the VLAN access list (VLAN filtering)</a></h2> +<p class="Pp">For historical reasons, the default + <code class="Nm">if_bridge</code> configuration allows all interfaces to + send tagged traffic for any VLAN, meaning that VLANs do not provide security + separation. To restrict which interfaces may communicate in which VLANs, + enable VLAN filtering on the bridge:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig bridge0 vlanfilter</pre> +</div> +<p class="Pp">This has the following effects on bridge members:</p> +<ul class="Bl-bullet Bd-indent"> + <li>No untagged frames will be accepted from a member interface unless the + interface has a PVID configured.</li> + <li>No tagged frames will be accepted from a member interface unless the VLAN + identifier is present in the interface's VLAN access list.</li> + <li>Frames with stacked tags (Q-in-Q) will not be accepted from a member + interface unless the <code class="Cm">qinq</code> option (see below) has + been configured for that member.</li> +</ul> +<p class="Pp">To configure the VLAN access list, use the + <a class="Xr">ifconfig(8)</a> <code class="Cm">iftagged</code>, + <code class="Cm">+iftagged</code> or <code class="Cm">-iftagged</code> + commands. For example, to allow an interface to communicate in VLANs 10, 20, + and any VLAN from 100 to 199:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig bridge0 iftagged ix0 10,20,100-199</pre> +</div> +</section> +<section class="Ss"> +<h2 class="Ss" id="IEEE_802.1ad_(Q-in-Q)_configuration"><a class="permalink" href="#IEEE_802.1ad_(Q-in-Q)_configuration">IEEE + 802.1ad (Q-in-Q) configuration</a></h2> +<p class="Pp">IEEE 802.1ad, also called Q-in-Q or “tag stacking”, + allows a single Ethernet frame to contain multiple tags. This allows one + Ethernet network to transport traffic between endpoints using its own VLAN + tags without interfering with any pre-existing tags, and is often used in + service provider networks to provide “virtual wire” Ethernet + services.</p> +<p class="Pp">When VLAN filtering is enabled, <code class="Nm">if_bridge</code> + does not permit member interfaces to send Q-in-Q frames, because in certain + configuration this allows “VLAN-hopping” attacks on the + bridge. For example, consider a bridge with port ix0 configured as a tagged + port in VLAN 10, and port ix1 configured as untagged in VLAN 10 and tagged + in VLAN 20. If ix0 is allowed to send Q-in-Q frames, then it can send a + frame with two tags: one for VLAN 10, followed by one for VLAN 20. When the + bridge forwards the frame to ix1, it will strip the VLAN tag for VLAN 10, + then forward the frame to ix1 with the tag for VLAN 20 intact, effectively + allowing ix1 to send traffic on VLAN 20 even though the bridge configuration + should not permit that.</p> +<p class="Pp">To permit an interface to send Q-in-Q frames, set the + <a class="Xr">ifconfig(8)</a> <code class="Cm">qinq</code> flag on the + interface. This is only required on the interface which will send Q-in-Q + frames, not the interface receiving the frames.</p> +<p class="Pp">Alternatively, set the <code class="Cm">defqinq</code> flag on the + bridge itself to enable Q-in-Q for all newly-added interfaces by + default.</p> +</section> +</section> +<section class="Sh"> +<h1 class="Sh" id="PACKET_FILTERING"><a class="permalink" href="#PACKET_FILTERING">PACKET + FILTERING</a></h1> +<p class="Pp">Packet filtering can be used with any firewall package that hooks + in via the <a class="Xr">pfil(9)</a> framework. When filtering is enabled, + bridged packets will pass through the filter inbound on the originating + interface, on the bridge interface and outbound on the appropriate + interfaces. Either stage can be disabled. The filtering behavior can be + controlled using <a class="Xr">sysctl(8)</a>:</p> +<dl class="Bl-tag"> + <dt id="net.link.bridge.pfil_onlyip"><var class="Va">net.link.bridge.pfil_onlyip</var></dt> + <dd>Controls the handling of non-IP packets which are not passed to + <a class="Xr">pfil(9)</a>. Set to <code class="Li">1</code> to only allow + IP packets to pass (subject to firewall rules), set to + <code class="Li">0</code> to unconditionally pass all non-IP Ethernet + frames.</dd> + <dt id="net.link.bridge.pfil_member"><var class="Va">net.link.bridge.pfil_member</var></dt> + <dd>Set to <code class="Li">1</code> to enable filtering on the incoming and + outgoing member interfaces, set to <code class="Li">0</code> to disable + it.</dd> + <dt id="net.link.bridge.pfil_bridge"><var class="Va">net.link.bridge.pfil_bridge</var></dt> + <dd>Set to <code class="Li">1</code> to enable filtering on the bridge + interface, set to <code class="Li">0</code> to disable it.</dd> + <dt id="net.link.bridge.pfil_local_phys"><var class="Va">net.link.bridge.pfil_local_phys</var></dt> + <dd>Set to <code class="Li">1</code> to additionally filter on the physical + interface for locally destined packets. Set to <code class="Li">0</code> + to disable this feature.</dd> + <dt id="net.link.bridge.ipfw"><var class="Va">net.link.bridge.ipfw</var></dt> + <dd>Set to <code class="Li">1</code> to enable layer2 filtering with + <a class="Xr">ipfirewall(4)</a>, set to <code class="Li">0</code> to + disable it. This needs to be enabled for <a class="Xr">dummynet(4)</a> + support. When <var class="Va">ipfw</var> is enabled, + <var class="Va">pfil_bridge</var> and <var class="Va">pfil_member</var> + will be disabled so that IPFW is not run twice; these can be re-enabled if + desired.</dd> + <dt id="net.link.bridge.ipfw_arp"><var class="Va">net.link.bridge.ipfw_arp</var></dt> + <dd>Set to <code class="Li">1</code> to enable layer2 ARP filtering with + <a class="Xr">ipfirewall(4)</a>, set to <code class="Li">0</code> to + disable it. Requires <var class="Va">ipfw</var> to be enabled.</dd> +</dl> +<p class="Pp">ARP and REVARP packets are forwarded without being filtered and + others that are not IP nor IPv6 packets are not forwarded when + <var class="Va">pfil_onlyip</var> is enabled. IPFW can filter Ethernet types + using <code class="Cm">mac-type</code> so all packets are passed to the + filter for processing.</p> +<p class="Pp">The packets originating from the bridging host will be seen by the + filter on the interface that is looked up in the routing table.</p> +<p class="Pp">The packets destined to the bridging host will be seen by the + filter on the interface with the MAC address equal to the packet's + destination MAC. There are situations when some of the bridge members are + sharing the same MAC address (for example the <a class="Xr">vlan(4)</a> + interfaces: they are currently sharing the MAC address of the parent + physical interface). It is not possible to distinguish between these + interfaces using their MAC address, excluding the case when the packet's + destination MAC address is equal to the MAC address of the interface on + which the packet was entered to the system. In this case the filter will see + the incoming packet on this interface. In all other cases the interface seen + by the packet filter is chosen from the list of bridge members with the same + MAC address and the result strongly depends on the member addition sequence + and the actual implementation of <code class="Nm">if_bridge</code>. It is + not recommended to rely on the order chosen by the current + <code class="Nm">if_bridge</code> implementation since it may change in the + future.</p> +<p class="Pp">The previous paragraph is best illustrated with the following + pictures. Let</p> +<ul class="Bl-bullet"> + <li>the MAC address of the incoming packet's destination is + <code class="Nm">nn:nn:nn:nn:nn:nn</code>,</li> + <li>the interface on which packet entered the system is + <code class="Nm">ifX</code>,</li> + <li><code class="Nm">ifX</code> MAC address is + <code class="Nm">xx:xx:xx:xx:xx:xx</code>,</li> + <li>there are possibly other bridge members with the same MAC address + <code class="Nm">xx:xx:xx:xx:xx:xx</code>,</li> + <li>the bridge has more than one interface that are sharing the same MAC + address <code class="Nm">yy:yy:yy:yy:yy:yy</code>; we will call them + <code class="Nm">vlanY1</code>, <code class="Nm">vlanY2</code>, etc.</li> +</ul> +<p class="Pp">If the MAC address <code class="Nm">nn:nn:nn:nn:nn:nn</code> is + equal to <code class="Nm">xx:xx:xx:xx:xx:xx</code> the filter will see the + packet on interface <code class="Nm">ifX</code> no matter if there are any + other bridge members carrying the same MAC address. But if the MAC address + <code class="Nm">nn:nn:nn:nn:nn:nn</code> is equal to + <code class="Nm">yy:yy:yy:yy:yy:yy</code> then the interface that will be + seen by the filter is one of the <code class="Nm">vlanYn</code>. It is not + possible to predict the name of the actual interface without the knowledge + of the system state and the <code class="Nm">if_bridge</code> implementation + details.</p> +<p class="Pp">This problem arises for any bridge members that are sharing the + same MAC address, not only to the <a class="Xr">vlan(4)</a> ones: they were + taken just as an example of such a situation. So if one wants to filter the + locally destined packets based on their interface name, one should be aware + of this implication. The described situation will appear at least on the + filtering bridges that are doing IP-forwarding; in some of such cases it is + better to assign the IP address only to the + <code class="Nm">if_bridge</code> interface and not to the bridge members. + Enabling <var class="Va">net.link.bridge.pfil_local_phys</var> will let you + do the additional filtering on the physical interface.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="NETMAP"><a class="permalink" href="#NETMAP">NETMAP</a></h1> +<p class="Pp"><a class="Xr">netmap(4)</a> applications may open a bridge + interface in emulated mode. The netmap application will receive all packets + which arrive from member interfaces. In particular, packets which would + otherwise be forwarded to another member interface will be received by the + netmap application.</p> +<p class="Pp">When the <a class="Xr">netmap(4)</a> application transmits a + packet to the host stack via the bridge interface, + <code class="Nm">if_bridge</code> receive it and attempts to determine its + ‘<code class="Li">source</code>’ interface by looking up the + source MAC address in the interface's learning tables. Packets for which no + matching source interface is found are dropped and the input error counter + is incremented. If a matching source interface is found, + <code class="Nm">if_bridge</code> treats the packet as though it was + received from the corresponding interface and handles it normally without + passing the packet back to <a class="Xr">netmap(4)</a>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="EXAMPLES"><a class="permalink" href="#EXAMPLES">EXAMPLES</a></h1> +<p class="Pp">The following when placed in the file + <span class="Pa">/etc/rc.conf</span> will cause a bridge called + “<code class="Li">bridge0</code>” to be created, and will add + the interfaces “<code class="Li">wlan0</code>” and + “<code class="Li">fxp0</code>” to the bridge, and then enable + packet forwarding. Such a configuration could be used to implement a simple + 802.11-to-Ethernet bridge (assuming the 802.11 interface is in ad-hoc + mode).</p> +<div class="Bd Pp Bd-indent Li"> +<pre>cloned_interfaces="bridge0" +ifconfig_bridge0="addm wlan0 addm fxp0 up"</pre> +</div> +<p class="Pp">For the bridge to forward packets, all member interfaces and the + bridge need to be up. The above example would also require:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>create_args_wlan0="wlanmode hostap" +ifconfig_wlan0="up ssid my_ap mode 11g" +ifconfig_fxp0="up"</pre> +</div> +<p class="Pp">The following will cause a bridge to be created with two VLANs, 10 + and 20, where the “<code class="Li">em</code>” interfaces can + only communicate in their assigned VLANs, while + “<code class="Li">ix0</code>” is a trunk port which can + communicate in either VLAN:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>cloned_interfaces="bridge0" +ifconfig_bridge0="vlanfilter \ + addm em0 untagged 10 \ + addm em1 untagged 10 \ + addm em2 untagged 20 \ + addm em3 untagged 20 \ + addm ix0 tagged 10,20" +ifconfig_em0="up" +ifconfig_em1="up" +ifconfig_em2="up" +ifconfig_em3="up" +ifconfig_ix0="up"</pre> +</div> +<p class="Pp">The previous example could be extended to allow the host to + communicate in VLANs 10 and 20:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>vlans_bridge0="10 20" +ifconfig_bridge0_10_ipv6="inet6 2001:db8:0:10::1/64" +ifconfig_bridge0_20_ipv6="inet6 2001:db8:0:20::1/64"</pre> +</div> +<p class="Pp">Consider a system with two 4-port Ethernet boards. The following + will cause a bridge consisting of all 8 ports with Rapid Spanning Tree + enabled to be created:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig bridge0 create +ifconfig bridge0 \ + addm fxp0 stp fxp0 \ + addm fxp1 stp fxp1 \ + addm fxp2 stp fxp2 \ + addm fxp3 stp fxp3 \ + addm fxp4 stp fxp4 \ + addm fxp5 stp fxp5 \ + addm fxp6 stp fxp6 \ + addm fxp7 stp fxp7 \ + up</pre> +</div> +<p class="Pp">The bridge can be used as a regular host interface at the same + time as bridging between its member ports. In this example, the bridge + connects em0 and em1, and will receive its IP address through DHCP:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>cloned_interfaces="bridge0" +ifconfig_bridge0="addm em0 addm em1 DHCP" +ifconfig_em0="up" +ifconfig_em1="up"</pre> +</div> +<p class="Pp">The bridge can tunnel Ethernet across an IP internet using the + EtherIP protocol. This can be combined with <a class="Xr">ipsec(4)</a> to + provide an encrypted connection. Create a <a class="Xr">gif(4)</a> interface + and set the local and remote IP addresses for the tunnel, these are reversed + on the remote bridge.</p> +<div class="Bd Pp Bd-indent Li"> +<pre>ifconfig gif0 create +ifconfig gif0 tunnel 1.2.3.4 5.6.7.8 up +ifconfig bridge0 create +ifconfig bridge0 addm fxp0 addm gif0 up</pre> +</div> +</section> +<section class="Sh"> +<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE + ALSO</a></h1> +<p class="Pp"><a class="Xr">gif(4)</a>, <a class="Xr">ipf(4)</a>, + <a class="Xr">ipfw(4)</a>, <a class="Xr">netmap(4)</a>, + <a class="Xr">pf(4)</a>, <a class="Xr">vlan(4)</a>, + <a class="Xr">ifconfig(8)</a></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> +<p class="Pp">The <code class="Nm">if_bridge</code> driver first appeared in + <span class="Ux">FreeBSD 6.0</span>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1> +<p class="Pp">The <code class="Nm">bridge</code> driver was originally written + by <span class="An">Jason L. Wright</span> + <<a class="Mt" href="mailto:jason@thought.net">jason@thought.net</a>> + as part of an undergraduate independent study at the University of North + Carolina at Greensboro.</p> +<p class="Pp">This version of the <code class="Nm">if_bridge</code> driver has + been heavily modified from the original version by <span class="An">Jason R. + Thorpe</span> + <<a class="Mt" href="mailto:thorpej@wasabisystems.com">thorpej@wasabisystems.com</a>>.</p> +<p class="Pp">Rapid Spanning Tree Protocol (RSTP) support was added by + <span class="An">Andrew Thompson</span> + <<a class="Mt" href="mailto:thompsa@FreeBSD.org">thompsa@FreeBSD.org</a>>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1> +<p class="Pp">The <code class="Nm">if_bridge</code> driver currently supports + only Ethernet and Ethernet-like (e.g., 802.11) network devices, which can be + configured with the same MTU size as the bridge device.</p> +</section> +</div> +<table class="foot"> + <tr> + <td class="foot-date">October 13, 2025</td> + <td class="foot-os">FreeBSD 15.0</td> + </tr> +</table> |