[FUG-BR] Queue

[Marcelo Costa]

man ipfw 

......

altq queue
             When a packet matches a rule with the altq keyword, the
ALTQ
             identifier for the given queue (see altq(4)) will be
attached.
             Note that this ALTQ tag is only meaningful for packets
going
             "out" of IPFW, and not being rejected or going to divert
sockets.
             Note that if there is insufficient memory at the time the
packet
             is processed, it will not be tagged, so it is wise to make
your
             ALTQ "default" queue policy account for this.  If multiple
altq
             rules match a single packet, only the first one adds the
ALTQ
             classification tag.  In doing so, traffic may be shaped by
using
             count altq queue rules for classification early in the
ruleset,
             then later applying the filtering decision.  For example,
             check-state and keep-state rules may come later and provide
the
             actual filtering decisions in addition to the fallback ALTQ
tag.

             You must run pfctl(8) to set up the queues before IPFW will
be
             able to look them up by name, and if the ALTQ disciplines
are
             rearranged, the rules in containing the queue identifiers
in the
             kernel will likely have gone stale and need to be reloaded.
             Stale queue identifiers will probably result in
misclassifica-
             tion.

             All system ALTQ processing can be turned on or off via ipfw
             enable altq and ipfw disable altq.  The usage of
             net.inet.ip.fw.one_pass is irrelevant to ALTQ traffic
shaping, as
             the actual rule action is followed always after adding an
ALTQ
             tag.

........

 Another typical application of the traffic shaper is to introduce some
     delay in the communication.  This can significantly affect
applications
     which do a lot of Remote Procedure Calls, and where the
round-trip-time
     of the connection often becomes a limiting factor much more than
band-
     width:

           ipfw add pipe 1 ip from any to any out
           ipfw add pipe 2 ip from any to any in
           ipfw pipe 1 config delay 250ms bw 1Mbit/s
           ipfw pipe 2 config delay 250ms bw 1Mbit/s

     Per-flow queueing can be useful for a variety of purposes.  A very
simple
     one is counting traffic:

           ipfw add pipe 1 tcp from any to any
           ipfw add pipe 1 udp from any to any
           ipfw add pipe 1 ip from any to any
           ipfw pipe 1 config mask all

     The above set of rules will create queues (and collect statistics)
for
     all traffic.  Because the pipes have no limitations, the only
effect is
     collecting statistics.  Note that we need 3 rules, not just the
last one,
     because when ipfw tries to match IP packets it will not consider
ports,
     so we would not see connections on separate ports as different
ones.

     A more sophisticated example is limiting the outbound traffic on a
net
     with per-host limits, rather than per-network limits:

           ipfw add pipe 1 ip from 192.168.2.0/24 to any out
           ipfw add pipe 2 ip from any to 192.168.2.0/24 in
           ipfw pipe 1 config mask src-ip 0x000000ff bw 200Kbit/s queue
           20Kbytes
           ipfw pipe 2 config mask dst-ip 0x000000ff bw 200Kbit/s queue
           20Kbytes


exemplo interesante

http://m0n0.ch/wall/list-dev/showmsg.php?id=6/29


O que acontece é que ipfw é projetado para rule match , o usual é
colocar um delay , mas altq com ipfw é possivel sim , a questão é que
parece que não é muito utilizado assim como o dummynet

[]'s