holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity
ed61406441
shorewall_code/STABLE/documentation/traffic_shaping.htm
teastep f04d58006f Changes for 1.3.13 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@402 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-01-14 20:32:45 +00:00

325 lines
14 KiB
HTML
Raw Blame History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Traffic Shaping</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Traffic Shaping/Control</font></h1>
</td>
</tr>
</tbody>
</table>
<p align="left">Beginning with version 1.2.0, Shorewall has limited support
for traffic shaping/control. In order to use traffic shaping under Shorewall,
it is essential that you get a copy of the <a
href="http://ds9a.nl/lartc">Linux Advanced Routing and Shaping HOWTO</a>,
version 0.3.0 or later. You must also install the iproute (iproute2) package
to provide the "ip" and "tc" utilities.</p>
<p align="left">Shorewall traffic shaping support consists of the following:</p>
<ul>
<li>A new <b>TC_ENABLED</b> parameter in /etc/shorewall.conf.
Traffic Shaping also requires that you enable packet mangling.</li>
<li>A new <b>CLEAR_TC </b>parameter in /etc/shorewall.conf (Added in Shorewall
1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the setting of
this variable determines whether Shorewall clears the traffic shaping configuration
during Shorewall [re]start and Shorewall stop. <br>
</li>
<li><b>/etc/shorewall/tcrules</b> - A file where you can specify
firewall marking of packets. The firewall mark value may be used to
classify packets for traffic shaping/control.<br>
</li>
<li><b>/etc/shorewall/tcstart </b>- A user-supplied file that
is sourced by Shorewall during "shorewall start" and which you can
use to define your traffic shaping disciplines and classes. I have
provided a <a href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a>
that does table-driven CBQ shaping but if you read the traffic shaping
sections of the HOWTO mentioned above, you can probably code your
own faster than you can learn how to use my sample. I personally use
<a href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall since
HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
HTB is a standard part of the kernel but iproute2 must be patched in
order to use it.<br>
<br>
In tcstart, when you want to run the 'tc' utility, use the
run_tc function supplied by shorewall if you want tc errors to stop
the firewall.<br>
<br>
You can generally use off-the-shelf traffic shaping scripts by simply
copying them to /etc/shorewall/tcstart. I use <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (HTB version)
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and
modified it according to the Wonder Shaper README). <b>WARNING: </b>If you
use use Masquerading or SNAT (i.e., you only have one external IP address)
then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb]
script won't work. Traffic shaping occurs after SNAT has already been applied
so when traffic shaping happens, all outbound traffic will have as a source
address the IP addresss of your firewall's external interface.<br>
</li>
<li><b>/etc/shorewall/tcclear</b> - A user-supplied file that
is sourced by Shorewall when it is clearing traffic shaping. This
file is normally not required as Shorewall's method of clearing qdisc
and filter definitions is pretty general.</li>
</ul>
Shorewall allows you to start traffic shaping when Shorewall itself starts
or it allows you to bring up traffic shaping when you bring up your interfaces.<br>
<br>
To start traffic shaping when Shorewall starts:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=Yes</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic shaping
rules.</li>
<li>Optionally supply an /etc/shorewall/tcclear script to stop traffic
shaping. That is usually unnecessary.</li>
<li>If your tcstart script uses the 'fwmark' classifier, you can mark packets
using entries in /etc/shorewall/tcrules.</li>
</ol>
To start traffic shaping when you bring up your network interfaces, you will
have to arrange for your traffic shaping configuration script to be run at
that time. How you do that is distribution dependent and will not be covered
here. You then should:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=No</li>
<li>Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.</li>
<li value="4">If your tcstart script uses the 'fwmark' classifier, you
can mark packets using entries in /etc/shorewall/tcrules.</li>
</ol>
<h3 align="left">Kernel Configuration</h3>
<p align="left">This screen shot show how I've configured QoS in my Kernel:</p>
<p align="center"><img border="0" src="images/QoS.png" width="590"
height="764">
</p>
<h3 align="left"><a name="tcrules"></a>/etc/shorewall/tcrules</h3>
<p align="left">The fwmark classifier provides a convenient way to classify
packets for traffic shaping. The /etc/shorewall/tcrules file provides
a means for specifying these marks in a tabular fashion.<br>
</p>
<p align="left">Normally, packet marking occurs in the PREROUTING chain before
any address rewriting takes place. This makes it impossible to mark inbound
packets based on their destination address when SNAT or Masquerading are
being used. Beginning with Shorewall 1.3.12, you can cause packet marking
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in
<a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
</p>
<p align="left">Columns in the file are as follows:</p>
<ul>
<li>MARK - Specifies the mark value is to be assigned in case
of a match. This is an integer in the range 1-255.<br>
<br>
Example - 5<br>
</li>
<li>SOURCE - The source of the packet. If the packet originates
on the firewall, place "fw" in this column. Otherwise, this is a
comma-separated list of interface names, IP addresses, MAC addresses in
<a href="Documentation.htm#MAC">Shorewall Format</a> and/or Subnets.<br>
<br>
Examples<br>
<20><><EFBFBD> eth0<br>
<20><><EFBFBD> 192.168.2.4,192.168.1.0/24<br>
</li>
<li>DEST -- Destination of the packet. Comma-separated list of
IP addresses and/or subnets.<br>
</li>
<li>PROTO - Protocol - Must be the name of a protocol from
/etc/protocol, a number or "all"<br>
</li>
<li>PORT(S) - Destination Ports. A comma-separated list of Port
names (from /etc/services), port numbers or port ranges (e.g., 21:22);
if the protocol is "icmp", this column is interpreted as the
destination icmp type(s).<br>
</li>
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client. If
omitted, any source port is acceptable. Specified as a comma-separate
list of port names, port numbers or port ranges.</li>
</ul>
<p align="left">Example 1 - All packets arriving on eth1 should be marked
with 1. All packets arriving on eth2 and eth3 should be marked with 2.
All packets originating on the firewall itself should be marked with 3.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>1</td>
<td>eth1</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
</tr>
<tr>
<td>2</td>
<td>eth2</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
</tr>
<tr>
<td valign="top">2<br>
</td>
<td valign="top">eth3<br>
</td>
<td valign="top">0.0.0.0/0<br>
</td>
<td valign="top">all<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td>3</td>
<td>fw</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
</tr>
</tbody>
</table>
<p align="left">Example 2 - All GRE (protocol 47) packets not originating
on the firewall and destined for 155.186.235.151 should be marked with
12.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>12</td>
<td>0.0.0.0/0</td>
<td>155.186.235.151</td>
<td>47</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
</tr>
</tbody>
</table>
<p align="left">Example 3 - All SSH packets originating in 192.168.1.0/24
and destined for 155.186.235.151 should be marked with 22.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>22</td>
<td>192.168.1.0/24</td>
<td>155.186.235.151</td>
<td>tcp</td>
<td>22</td>
<td><EFBFBD></td>
</tr>
</tbody>
</table>
<h3>My Setup<br>
</h3>
<p>While I am currently using the HTB version of <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (I just copied
wshaper.htb to <b>/etc/shorewall/tcstart</b> and modified it as shown in
the Wondershaper README), I have also run with the following set of hand-crafted
rules in my <b>/etc/shorewall/tcstart</b> file:<br>
</p>
<blockquote>
<pre>run_tc qdisc add dev eth0 root handle 1: htb default 30<br><br>run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k<br><br>echo "<22><> Added Top Level Class -- rate 384kbit"</pre>
<pre>run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1<br>run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0<br>run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit<69> ceil 384kbit burst 15k quantum 1500 prio 1</pre>
<pre>echo "<22><> Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"</pre>
<pre>run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5<br>run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10<br>run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5</pre>
<pre>echo "<22><> Enabled PFIFO on Second Level Classes"</pre>
<pre>run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10<br>run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20<br>run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30</pre>
<pre>echo "<22><> Defined fwmark filters"<br></pre>
</blockquote>
<p>My tcrules file that went with this tcstart file is shown in Example 1
above. You can look at my <a href="myfiles.htm">network configuration</a>
to get an idea of why I wanted these particular rules.<br>
</p>
<ol>
<li>I wanted to allow up to 140kbits/second for traffic outbound from
my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic
can use all available bandwidth if there is no traffic from the local systems
or from my laptop or firewall).</li>
<li>My laptop and local systems could use up to 224kbits/second.</li>
<li>My firewall could use up to 20kbits/second.<br>
</li>
</ol>
<p><font size="2">Last Updated 12/31/2002 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
<20> <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>
View Git Blame Copy Permalink