| net.link.ether.bridge.enable |
| || Set to 1 to enable bridging, set to 0 to disable it. |
| net.link.ether.bridge.ipfw |
| || Set to 1 to enable ipfw(8) processing of bridged packets. Note that ipfw(8) rules only apply to IP packets. Non-IP packets are accepted by default. See the BUGS section and the ipfw(8) manpage for more details on the interaction of bridging and the firewall. |
| net.link.ether.bridge.ipf |
| || Set to 1 to enable ipf(8) processing of bridged packets. Note that ipf(8) rules only apply to IP packets. Non-IP packets are accepted by default. |
| net.link.ether.bridge.config |
| || Set to the list of interfaces to bridge. Interfaces are separated by spaces, commas or tabs. Each interface can be optionally followed by a colon and an integer indicating the cluster it belongs to (defaults to 1 if the cluster-ID is missing), e.g. ""dc0:1,dc1,vlan0:3 dc2:3"" will put dc0 and dc1 in cluster number 1, and vlan0 and dc2 in cluster number 3. See the EXAMPLES section for more examples. |
The list of interfaces is rescanned every time the list is modified, bridging is enabled, or new interfaces are created or destroyed. An explicit request to refresh the bridge configuration can also be done by writing any value to net.link.ether.bridge.refresh. Interfaces that are in the list but cannot be used for bridging (because they are non-existing, or not Ethernet or VLAN) are not used and a warning message is generated.
Bridging requires interfaces to be put in promiscuous mode, and transmit packets with Ethernet source addresses different than their own. Some interfaces (e.g. wi(4)) do not support this functionality. Also, bridging is not compatible with interfaces which use hardware loopback, because there is no way to tell locally generated packets from externally generated ones.
A simple bridge configuration with three interfaces in the same cluster can be set as follows. No cluster-ID is specified here, which will cause the interfaces to appear as part of cluster #1.
If you do not know what actual interfaces will be present on your system, you can just put all existing interfaces in the configuration, as follows:
sysctl net.link.ether.bridge.config= "ifconfig -l"
This will result in a space-separated list of interfaces. Out of the list, only Ethernet and VLAN interfaces will be used for bridging, whereas for others the kernel will produce a warning message.
More complex configurations can be used to create multiple clusters, e.g.
will create two completely independent clusters.
Finally, interesting configurations involve VLANs and parent interfaces. As an example, the following configuration will use interface dc0 as a "trunk" interface, and pass packets for 802.1q VLANs 10 and 20 to physical interfaces dc1 and dc2, respectively:
ifconfig vlan0 vlan 10 vlandev dc0
ifconfig vlan1 vlan 20 vlandev dc0
Note how there is no relation between the 802.1q VLAN identifiers (10 and 20) and the cluster-IDs (34 and 56) used in the bridge.config variable.
Note also that the trunk interface does not even appear in the bridge.config, as VLAN tag insertion/removal is performed by the vlan(4) devices. When using VLAN devices, care must be taken by not creating loops between these devices and their parent interfaces.
ip(4), ng_bridge(4), vlan(4), ipf(8), ipfw(8), sysctl(8)