svn commit: r353120 - head/share/man/man4
Jens Schweikhardt
schweikh at FreeBSD.org
Sat Oct 5 09:59:01 UTC 2019
Author: schweikh
Date: Sat Oct 5 09:59:00 2019
New Revision: 353120
URL: https://svnweb.freebsd.org/changeset/base/353120
Log:
Correct grammos and typos.
Modified:
head/share/man/man4/bridge.4
Modified: head/share/man/man4/bridge.4
==============================================================================
--- head/share/man/man4/bridge.4 Sat Oct 5 09:46:11 2019 (r353119)
+++ head/share/man/man4/bridge.4 Sat Oct 5 09:59:00 2019 (r353120)
@@ -87,7 +87,7 @@ This address is guaranteed to be unique
across all
.Nm
interfaces on the local machine.
-Thus you can theoretically have two bridges on the different machines with
+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
.Xr ifconfig 8 .
@@ -96,17 +96,17 @@ If
.Xr sysctl 8
node
.Va net.link.bridge.inherit_mac
-has non-zero value, newly created bridge will inherit MAC address
-from its first member instead of choosing random link-level address.
-This will provide more predictable bridge MAC without any
+has non-zero value, a newly created bridge will inherit its MAC address
+from its first member instead of choosing a random link-level address.
+This provides a 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
.Xr ng_pppoe 4
and
.Xr ppp 8 .
-Now this feature is considered as experimental and is turned off
-by-default.
+Currently this feature is considered experimental and is turned off
+by default.
.Pp
A bridge can be used to provide several services, such as a simple
802.11-to-Ethernet bridge for wireless hosts, and traffic isolation.
@@ -127,13 +127,13 @@ in
.Xr rc.conf 5 .
.Pp
The MTU of the first member interface to be added is used as the bridge MTU.
-All additional members are required to have exactly the same value.
+All additional members are required to have exactly the same MTU value.
.Pp
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 capabilities in run time may cause NIC reinit and the link flap.
+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.
.Pp
The bridge supports
.Dq monitor mode ,
@@ -167,7 +167,7 @@ ifconfig_bridge0_ipv6="inet6 auto_linklocal"
However, the
.Li AF_INET6
address family has a concept of scope zone.
-Bridging multiple interfaces change the zone configuration because
+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
@@ -180,10 +180,10 @@ This situation is clearly against the description
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
+it can cause some counterintuitive or undesirable behavior in some
+edge cases when both, the
.Nm
-interface and one of the member interface have an IPv6 address
+interface and one of the member interfaces, have an IPv6 address
and applications use both of them.
.Pp
To prevent this situation,
@@ -209,9 +209,9 @@ Note that
.Li ACCEPT_RTADV
and
.Li AUTO_LINKLOCAL
-interface flag are not enabled by default on
+interface flags are not enabled by default on
.Nm
-interface even when
+interfaces even when
.Va net.inet6.ip6.accept_rtadv
and/or
.Va net.inet6.ip6.auto_linklocal
@@ -238,9 +238,9 @@ command in
.Pp
The bridge can log STP port changes to
.Xr syslog 3
-by enabling the
+by setting the
.Va net.link.bridge.log_stp
-variable using
+node using
.Xr sysctl 8 .
.Sh PACKET FILTERING
Packet filtering can be used with any firewall package that hooks in via the
@@ -348,7 +348,7 @@ actual implementation of
.Nm .
It is not recommended to rely on the order chosen by the current
.Nm
-implementation: it can be changed in the future.
+implementation since it may change in the future.
.Pp
The previous paragraph is best illustrated with the following
pictures.
@@ -377,17 +377,17 @@ we will call them
etc.
.El
.Pp
-Then if the MAC address
+If the MAC address
.Nm nn:nn:nn:nn:nn:nn
-is equal to the
+is equal to
.Nm xx:xx:xx:xx:xx:xx
-then the filter will see the packet on the interface
+the filter will see the packet on interface
.Nm ifX
no matter if there are any other bridge members carrying the same
MAC address.
But if the MAC address
.Nm nn:nn:nn:nn:nn:nn
-is equal to the
+is equal to
.Nm yy:yy:yy:yy:yy:yy
then the interface that will be seen by the filter is one of the
.Nm vlanYn .
@@ -399,8 +399,8 @@ implementation details.
This problem arises for any bridge members that are sharing the same
MAC address, not only to the
.Xr vlan 4
-ones: they we taken just as the example of such situation.
-So if one wants the filter the locally destined packets based on
+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
@@ -484,7 +484,7 @@ ifconfig bridge0 addm fxp0 addm gif0 up
Note that
.Fx
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
+For more details and workaround, see the
.Xr gif 4
manual page.
.Sh SEE ALSO
More information about the svn-src-head
mailing list