svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
if_bridge(4)
To compile this driver into the kernel, place the following line
in your kernel configuration file: Alternatively, to load the
driver as a module at boot time, place the following lines in
if_bridge_load="YES" bridgestp_load="YES" The driver creates a
logical link between two or more IEEE 802 networks that use the
same (or 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. Each interface is cre‐
ated at runtime using interface cloning. This is most easily
done with the command or using the variable in The interface ran‐
domly chooses a link (MAC) address in the range reserved for lo‐
cally administered addresses when it is created. This address is
guaranteed to be unique across all interfaces on the local ma‐
chine. Thus you can theoretically have two bridges on the dif‐
ferent machines with the same link addresses. The address can be
changed by assigning the desired link address using If node has
non-zero value, newly created bridge will inherit MAC address
from its first member instead of choosing random link-level ad‐
dress. This will provide more predictable bridge MAC without any
additional configuration, but currently this feature is known to
break some L2 protocols, for example PPPoE that is provided by
and Now this feature is considered as experimental and is turned
off by-default. A bridge can be used to provide several ser‐
vices, such as a simple 802.11-to-Ethernet bridge for wireless
hosts, and traffic isolation. A bridge works like a switch, for‐
warding 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 for‐
ward the traffic selectively. All the bridged member interfaces
need to be up in order to pass network traffic. These can be en‐
abled using or in The MTU of the first member interface to be
added is used as the bridge MTU. All additional members are re‐
quired to have exactly the same value. The TOE, TSO, TXCSUM and
TXCSUM6 capabilities on all interfaces added to the bridge are
disabled if any of the interfaces doesn't support/enable them.
The LRO capability is always disabled. All the capabilities are
restored when the interface is removed from bridge. Changing ca‐
pabilities in run time may cause NIC reinit and the link flap.
The bridge supports where the packets are discarded after pro‐
cessing, and are not processed or forwarded further. This can be
used to multiplex the input of two or more interfaces into a sin‐
gle stream. This is useful for reconstructing the traffic for
network taps that transmit the RX/TX signals out through two sep‐
arate interfaces. supports the address family on bridge inter‐
faces. The following variable configures an IPv6 link-local ad‐
dress on interface: ifconfig_bridge0_ipv6="up" or in a more ex‐
plicit manner: ifconfig_bridge0_ipv6="inet6 auto_linklocal" How‐
ever, the address family has a concept of scope zone. Bridging
multiple interfaces change the zone configuration because multi‐
ple 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 interface has another single, aggregated link-local scope
zone at the same time. This situation is clearly against the de‐
scription in Section 5, RFC 4007. Although it works in most
cases, it can cause some conterintuitive or undesirable behavior
in some edge cases when both of the interface and one of the mem‐
ber interface have an IPv6 address and applications use both of
them. To prevent this situation, checks whether a link-local
scoped IPv6 address is configured on a member interface to be
added and the interface. When the interface has IPv6 addresses,
IPv6 addresses on the member interface will be automatically re‐
moved before the interface is added. This behavior can be dis‐
abled by setting variable to Note that and interface flag are not
enabled by default on interface even when and/or is set to The
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. RSTP provides faster spanning tree
convergence than legacy STP, the protocol will exchange informa‐
tion with neighbouring switches to quickly transition to forward‐
ing without creating loops. 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 command in
The bridge can log STP port changes to by enabling the variable
using Packet filtering can be used with any firewall package that
hooks in via the 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 appropri‐
ate interfaces. Either stage can be disabled. The filtering be‐
haviour can be controlled using Controls the handling of non-IP
packets which are not passed to Set to to only allow IP packets
to pass (subject to firewall rules), set to to unconditionally
pass all non-IP Ethernet frames. Set to to enable filtering on
the incoming and outgoing member interfaces, set to to disable
it. Set to to enable filtering on the bridge interface, set to
to disable it. Set to to additionally filter on the physical in‐
terface for locally destined packets. Set to to disable this
feature. Set to to enable layer2 filtering with set to to dis‐
able it. This needs to be enabled for support. When is enabled,
and will be disabled so that IPFW is not run twice; these can be
re-enabled if desired. Set to to enable layer2 ARP filtering
with set to to disable it. Requires to be enabled. ARP and RE‐
VARP packets are forwarded without being filtered and others that
are not IP nor IPv6 packets are not forwarded when is enabled.
IPFW can filter Ethernet types using so all packets are passed to
the filter for processing. The packets originating from the
bridging host will be seen by the filter on the interface that is
looked up in the routing table. 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 interfaces: they are currently shar‐
ing 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 ad‐
dress 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 It is not recommended to rely on the order cho‐
sen by the current implementation: it can be changed in the fu‐
ture. The previous paragraph is best illustrated with the fol‐
lowing pictures. Let the MAC address of the incoming packet's
destination is the interface on which packet entered the system
is MAC address is there are possibly other bridge members with
the same MAC address the bridge has more than one interface that
are sharing the same MAC address we will call them etc. Then if
the MAC address is equal to the then the filter will see the
packet on the interface no matter if there are any other bridge
members carrying the same MAC address. But if the MAC address is
equal to the then the interface that will be seen by the filter
is one of the It is not possible to predict the name of the ac‐
tual interface without the knowledge of the system state and the
implementation details. This problem arises for any bridge mem‐
bers that are sharing the same MAC address, not only to the ones:
they we taken just as the example of such situation. So if one
wants the filter the locally destined packets based on their in‐
terface name, one should be aware of this implication. The de‐
scribed 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 interface and not to the
bridge members. Enabling will let you do the additional filter‐
ing on the physical interface. The following when placed in the
file will cause a bridge called to be created, and will add the
interfaces and 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). cloned_interfaces="bridge0" ifconfig_bridge0="addm
wlan0 addm fxp0 up" For the bridge to forward packets, all member
interfaces and the bridge need to be up. The above example would
also require: create_args_wlan0="wlanmode hostap" ifcon‐
fig_wlan0="up ssid my_ap mode 11g" ifconfig_fxp0="up" Consider a
system with two 4-port Ethernet boards. The following will cause
a bridge consisting of all 8 ports with Rapid Spanning Tree en‐
abled to be created: 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 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: cloned_interfaces="bridge0" ifconfig_bridge0="addm
em0 addm em1 DHCP" ifconfig_em0="up" ifconfig_em1="up" The bridge
can tunnel Ethernet across an IP internet using the EtherIP pro‐
tocol. This can be combined with to provide an encrypted connec‐
tion. Create a interface and set the local and remote IP ad‐
dresses for the tunnel, these are reversed on the remote bridge.
ifconfig gif0 create ifconfig gif0 tunnel 1.2.3.4 5.6.7.8 up if‐
config bridge0 create ifconfig bridge0 addm fxp0 addm gif0 up
Note that 6.1, 6.2, 6.3, 7.0, 7.1, and 7.2 have a bug in the
EtherIP protocol. For more details and workaround, see manual
page. The driver first appeared in The driver was originally
written by as part of an undergraduate independent study at the
University of North Carolina at Greensboro. This version of the
driver has been heavily modified from the original version by
Rapid Spanning Tree Protocol (RSTP) support was added by The dri‐
ver currently supports only Ethernet and Ethernet-like (e.g.,
802.11) network devices, with exactly the same interface MTU size
as the bridge device.