Externalize the 'flow' classifier

This commit is contained in:
Tom Eastep 2009-05-08 14:05:27 -07:00
parent 8f1ea63711
commit e1771ebead
3 changed files with 29 additions and 2 deletions

View File

@ -1058,7 +1058,7 @@ sub setup_traffic_shaping() {
}
}
emit "run_tc filter add dev $device protocol all prio 1 parent $classnum: protocol ip handle $classnum flow hash keys $tcref->{flow} divisor 1024" if $tcref->{flow};
emit "run_tc filter add dev $device protocol all prio 1 parent $classnum: handle $classnum flow hash keys $tcref->{flow} divisor 1024" if $tcref->{flow};
#
# options
#

View File

@ -27,6 +27,10 @@ Changes in Shorewall 4.3.10
10) Fix 'iprange' command.
11) Make traffic shaping work better with IPv6.
12) Externalize 'flow'.
Changes in Shorewall 4.3.9
1) Logging rules now create separate chain.

View File

@ -100,7 +100,30 @@ None.
N E W F E A T U R E S I N 4 . 3 . 11
----------------------------------------------------------------------------
None.
1) Shorewall attaches an SFQ queuing discipline to each leaf HTB
class. SFQ ensures that each 'flow' gets equal access to the
interface.
The default definition of a 'flow' corresponds to a TCP
connection. So if one internal system is running BitTorrent, for
example, it can have lots of 'flows' and can thus take up a larger
share of the bandwidth than a system having only a single active
connection.
The 'flow' classifier (module cls_flow) works around this by
letting you define what a 'flow' is. The clasifier must be used
carefully or it can block off all traffic on an interface!
To use the 'flow' classifier, you specify 'flow=<keys>' in the
OPTIONS column of an HTB leaf class (one that has no
sub-classes). I recommend that you use the following:
Shaping internet-bound traffic flow=nfct-src
Shaping traffic bound for your
local net flow=dst
These will cause a 'flow' to consists of the traffic to/from each
internal system.
----------------------------------------------------------------------------
N E W F E A T U R E S IN 4 . 3