Fixed style bugs of rev 1.66.
This commit is contained in:
Ruslan Ermilov
parent
a54185c7ba
commit
e439c30cf4
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=61570
116
sbin/ipfw/ipfw.8
116
sbin/ipfw/ipfw.8
@ -49,6 +49,7 @@
|
||||
.Cm pipe
|
||||
.Es \&{ \&}
|
||||
.En Cm delete | list | show
|
||||
.Op Ar number ...
|
||||
.Nm ipfw
|
||||
.Cm queue
|
||||
.Ar number
|
||||
@ -760,7 +761,8 @@ traffic shaper.
|
||||
The shaper operates by dividing packets into
|
||||
.Em flows
|
||||
according to a user-specified mask on different fields
|
||||
of the IP header. Packets belonging to the same flow are then passed to two
|
||||
of the IP header.
|
||||
Packets belonging to the same flow are then passed to two
|
||||
different objects, named
|
||||
.Em pipe
|
||||
or
|
||||
@ -768,9 +770,9 @@ or
|
||||
.Pp
|
||||
A
|
||||
.Em pipe
|
||||
which emulate a link with given bandwidth, propagation delay,
|
||||
queue size and packet loss rate. Packets transit through
|
||||
the pipe according to its parameters.
|
||||
emulates a link with given bandwidth, propagation delay,
|
||||
queue size and packet loss rate.
|
||||
Packets transit through the pipe according to its parameters.
|
||||
.Pp
|
||||
A
|
||||
.Em queue
|
||||
@ -784,7 +786,7 @@ The
|
||||
pipe configuration format is the following:
|
||||
.Bd -ragged
|
||||
.Cm pipe Ar number Cm config
|
||||
.Op Cm bw Ar bandwidth|device
|
||||
.Op Cm bw Ar bandwidth | device
|
||||
.Op Cm delay Ar ms-delay
|
||||
.Oo
|
||||
.Cm queue
|
||||
@ -794,7 +796,16 @@ pipe configuration format is the following:
|
||||
.Op Cm plr Ar loss-probability
|
||||
.Op Cm mask Ar mask-specifier
|
||||
.Op Cm buckets Ar hash-table-size
|
||||
.Op Cm red|gred Ar w_q/min_th/max_th/max_p
|
||||
.Oo
|
||||
.Cm red | gred
|
||||
.Sm off
|
||||
.Ar w_q No / Xo
|
||||
.Ar min_th No /
|
||||
.Ar max_th No /
|
||||
.Ar max_p
|
||||
.Xc
|
||||
.Sm on
|
||||
.Oc
|
||||
.Ed
|
||||
.Pp
|
||||
The
|
||||
@ -812,12 +823,21 @@ queue configuration format is the following:
|
||||
.Op Cm plr Ar loss-probability
|
||||
.Op Cm mask Ar mask-specifier
|
||||
.Op Cm buckets Ar hash-table-size
|
||||
.Op Cm red|gred Ar w_q/min_th/max_th/max_p
|
||||
.Oo
|
||||
.Cm red | gred
|
||||
.Sm off
|
||||
.Ar w_q No / Xo
|
||||
.Ar min_th No /
|
||||
.Ar max_th No /
|
||||
.Ar max_p
|
||||
.Xc
|
||||
.Sm on
|
||||
.Oc
|
||||
.Ed
|
||||
|
||||
.Pp
|
||||
The following parameters can be configured for a pipe:
|
||||
.Bl -tag -width indent
|
||||
.It Cm bw Ar bandwidth|device
|
||||
.It Cm bw Ar bandwidth | device
|
||||
Bandwidth, measured in
|
||||
.Sm off
|
||||
.Oo
|
||||
@ -829,11 +849,17 @@ Bandwidth, measured in
|
||||
.Pp
|
||||
A value of 0 (default) means unlimited bandwidth.
|
||||
The unit must follow immediately the number, as in
|
||||
.Pp
|
||||
.Dl "ipfw pipe 1 config bw 300Kbit/s queue 50KBytes"
|
||||
If a device name is specified instead of of a numeric
|
||||
.Pp
|
||||
If a device name is specified instead of a numeric
|
||||
value, then the transmit clock is supplied by the specified
|
||||
device. At the moment only the "tun" device supports this
|
||||
functionality, for use in conjunction with ppp.
|
||||
device.
|
||||
At the moment only the
|
||||
.Xr tun 4
|
||||
device supports this
|
||||
functionality, for use in conjunction with
|
||||
.Xr ppp 8 .
|
||||
.It Cm delay Ar ms-delay
|
||||
Propagation delay, measured in milliseconds.
|
||||
The value is rounded to the next multiple of the clock tick
|
||||
@ -869,6 +895,7 @@ is a floating-point number between 0 and 1, with 0 meaning no
|
||||
loss, 1 meaning 100% loss.
|
||||
The loss rate is internally represented on 31 bits.
|
||||
.It Cm mask Ar mask-specifier
|
||||
The
|
||||
.Xr dummynet 4
|
||||
lets you to create per-flow queues.
|
||||
A flow identifier is constructed by masking the IP addresses,
|
||||
@ -887,7 +914,8 @@ where the latter means all bits in all fields are significant.
|
||||
When used within a
|
||||
.Ar pipe
|
||||
configuration, each flow is assigned a rate equal
|
||||
to the rate of the pipe. When used within a
|
||||
to the rate of the pipe.
|
||||
When used within a
|
||||
.Ar queue
|
||||
configuration, each flow is assigned a weight equal to the
|
||||
weight of the queue, and all flows insisting on the same pipe
|
||||
@ -901,32 +929,50 @@ variable
|
||||
.Em net.inet.ip.dummynet.hash_size ,
|
||||
allowed range is 16 to 1024.
|
||||
.It Cm pipe Ar pipe_nr
|
||||
Connects a queue to the specified pipe. Multiple queues (usually
|
||||
Connects a queue to the specified pipe.
|
||||
Multiple queues (usually
|
||||
with different weights) can be connected to the same pipe, which
|
||||
specifies the aggregate rate for the set of queues.
|
||||
.It Cm weight Ar weight
|
||||
Specifies the weight to be used for flows matching this queue.
|
||||
The weight must be in the range 1..100, and defaults to 1.
|
||||
.It Cm red|gred Ar w_q/min_th/max_th/max_p
|
||||
Make use of the RED queue management algorithm. w_q and max_p are floating
|
||||
point number between 0 and 1 (0 not included), while min_th and max_th are
|
||||
integer number specifying thresholds for queue management (thresholds
|
||||
are computed in bytes if the queue has been defined in bytes, in slots
|
||||
otherwise).
|
||||
The
|
||||
.Xr dummynet 4
|
||||
also supports the gentle RED variant (gred).
|
||||
Three
|
||||
.Xr sysctl 8
|
||||
variables can be used to control the RED behaviour:
|
||||
.Em net.inet.ip.dummynet.red_lookup_depth ,
|
||||
.It Cm red | gred Xo
|
||||
.Sm off
|
||||
.Ar w_q No /
|
||||
.Ar min_th No /
|
||||
.Ar max_th No /
|
||||
.Ar max_p
|
||||
.Sm on
|
||||
.Xc
|
||||
Make use of the RED queue management algorithm.
|
||||
.Ar w_q
|
||||
and
|
||||
.Ar max_p
|
||||
are floating
|
||||
point numbers between 0 and 1 (0 not included), while
|
||||
.Ar min_th
|
||||
and
|
||||
.Ar max_th
|
||||
are integer numbers specifying thresholds for queue management
|
||||
(thresholds are computed in bytes if the queue has been defined
|
||||
in bytes, in slots otherwise).
|
||||
The
|
||||
.Xr dummynet 4
|
||||
also supports the gentle RED variant (gred).
|
||||
Three
|
||||
.Xr sysctl 8
|
||||
variables can be used to control the RED behaviour:
|
||||
.Bl -tag -width indent
|
||||
.It Em net.inet.ip.dummynet.red_lookup_depth
|
||||
specifies the accuracy in computing the average queue
|
||||
when the link is idle (default to 256, must be greater than zero);
|
||||
.Em net.inet.ip.dummynet.red_avg_pkt_size ,
|
||||
specifies the expected average packet size (default to 512, must be greater than zero);
|
||||
.Em net.inet.ip.dummynet.red_max_pkt_size ,
|
||||
specifies the expected maximum packet size, only used when queue
|
||||
thresholds are in bytes (default to 1500, must be greater than zero).
|
||||
when the link is idle (defaults to 256, must be greater than zero)
|
||||
.It Em net.inet.ip.dummynet.red_avg_pkt_size
|
||||
specifies the expected average packet size (defaults to 512, must be
|
||||
greater than zero)
|
||||
.It Em net.inet.ip.dummynet.red_max_pkt_size
|
||||
specifies the expected maximum packet size, only used when queue
|
||||
thresholds are in bytes (defaults to 1500, must be greater than zero).
|
||||
.El
|
||||
.El
|
||||
.Sh CHECKLIST
|
||||
Here are some important points to consider when designing your
|
||||
@ -1158,8 +1204,8 @@ Ethernet, IRDA).
|
||||
It is not necessary that both pipes have the same configuration,
|
||||
so we can also simulate asymmetric links.
|
||||
.Pp
|
||||
Should we like to verify network performance with the RED queue
|
||||
management algorithm:
|
||||
Should we like to verify network performance with the RED queue
|
||||
management algorithm:
|
||||
.Pp
|
||||
.Dl "ipfw add pipe 1 ip from any to any"
|
||||
.Dl "ipfw pipe 1 config bw 500Kbit/s queue 100 red 0.002/30/80/0.1"
|
||||
|
||||
Loading…
Reference in New Issue
Block a user