This file allows you to define the incoming and outgoing bandwidth for the devices you want traffic shaping to be enabled. That means, if you want to use traffic shaping for a device, you have to define it here. For additional information, see shorewall-tcdevices (5).

Columns in the file are as follows:

#INTERFACE    IN-BANDWITH      OUT-BANDWIDTH
ppp0           6000kbit         500kbit

This file allows you to define the actual classes that are used to split the outgoing traffic. For additional information, see shorewall-tcclasses (5).

The fwmark classifier provides a convenient way to classify packets for traffic shaping. The “/etc/shorewall/tcrules” file is used for specifying these marks in a tabular fashion. For an in-depth look at the packet marking facility in Netfilter/Shorewall, please see this article.

For marking forwarded traffic, you must either set MARK_IN_FORWARD_CHAIN=Yes shorewall.conf or by using the :F qualifier (see below).

See shorewall-mangle(5) and shorewall-tcrules(5) for a description of the entries in these files. Note that the mangle file superseded the tcrules file in Shorewall 4.6.0.

The following examples are for the mangle file.

#ACTION       SOURCE    DESTINATION    PROTOCOL   PORT(S)
MARK(1)       eth1      0.0.0.0/0      all
MARK(2)       eth2      0.0.0.0/0      all
MARK(2)       eth3      0.0.0.0/0      all
MARK(3)       $FW       0.0.0.0/0      all

#ACTION       SOURCE    DESTINATION     PROTOCOL   PORT(S)
MARK(12):T    0.0.0.0/0 155.182.235.151 47

#ACTION       SOURCE         DESTINATION     PROTOCOL   PORT(S)
MARK(22):T    192.168.1.0/24 155.182.235.151 tcp        22

#ACTION           SOURCE         DESTINATION     PROTOCOL   PORT(S)         CLIENT
#                                                                           PORT(S)
CLASSIFY(1:110)   0.0.0.0/0      0.0.0.0/0       tcp        22
CLASSIFY(1:110)   0.0.0.0/0      0.0.0.0/0       tcp        -               22

#ACTION        SOURCE         DESTINATION     PROTOCOL   PORT(S)       CLIENT   USER/     TEST
#                                                                      PORT(S)  GROUP
MARK(1)        0.0.0.0/0      0.0.0.0/0       icmp       echo-request
MARK(1)        0.0.0.0/0      0.0.0.0/0       icmp       echo-reply

RESTORE        0.0.0.0/0      0.0.0.0/0       all        -             -        -         0
CONTINUE       0.0.0.0/0      0.0.0.0/0       all        -             -        -         !0
MARK(4)        0.0.0.0/0      0.0.0.0/0       ipp2p:all
SAVE           0.0.0.0/0      0.0.0.0/0       all        -             -        -         !0

#ACTION  SOURCE         DESTINATION     PROTOCOL   PORT(S)       CLIENT   USER/     TEST      CONNBYTES      TOS      HELPER
#                                                                PORT(S)  GROUP
RESTORE  0.0.0.0/0      0.0.0.0/0       all        -             -        -         0
CONTINUE 0.0.0.0/0      0.0.0.0/0       all        -             -        -         !0
1        0.0.0.0/0      0.0.0.0/0       all        -             -        -         -         -              -        sip
SAVE     0.0.0.0/0      0.0.0.0/0       all        -             -        -         !0

If you use ppp/pppoe/pppoa) to connect to your Internet provider and you use traffic shaping you need to restart shorewall traffic shaping. The reason for this is, that if the ppp connection gets restarted (and it usually does this at least daily), all “tc” filters/qdiscs related to that interface are deleted.

The easiest way to achieve this, is just to restart shorewall once the link is up. To achieve this add a small executable script to“/etc/ppp/ip-up.d”.

#! /bin/sh

/sbin/shorewall refresh

Beginning with Shorewall 4.4.15, the traffic-shaping configuration in the tcdevices, tcclasses and tcfilters files can be shared between Shorewall and Shorewall6. Only one of the products can control the configuration but the other can configure CLASSIFY rules in its own mangle or tcrules file that refer to the shared classes.

To defined the configuration in Shorewall and shared it with Shorewall6:

Shorewall6 compilations to have access to the tcdevices and tcclasses files although it will create no output. That access allows CLASSIFY rules in /etc/shorewall6/mangle to be validated against the TC configuration.

In this configuration, it is Shorewall that controls TC configuration (except for IPv6 mangle). You can reverse the settings in the files if you want to control the configuration using Shorewall6.

Some network administrators feel that they have to divy up their available bandwidth by IP address rather than by prioritizing the traffic based on the type of traffic. This gets really awkward when there are a large number of local IP addresses.

This section describes the Shorewall facility for making this configuration less tedious (and a lot more efficient). Note that it requires that you install xtables-addons. So before you try this facility, we suggest that first you add the following OPTION to each external interface described in /etc/shorewall/tcdevices:

flow=nfct-src

If you shape traffic on your internal interface(s), then add this to their entries:

flow=dst

You may find that this simple change is all that is needed to control bandwidth hogs like Bit Torrent. If it doesn't, then proceed as described in this section.

The facility has two components:

The facility is currently only available with IPv4.

In a sense, the IPMARK target is more like an IPCLASSIFY target in that the mark value is later interpreted as a class ID. A packet mark is 32 bits wide; so is a class ID. The major class occupies the high-order 16 bits and the minor class occupies the low-order 16 bits. So the class ID 1:4ff (remember that class IDs are always in hex) is equivalent to a mark value of 0x104ff. Remember that Shorewall uses the interface number as the major number where the first interface in tcdevices has major number 1, the second has major number 2, and so on.

The IPMARK target assigns a mark to each matching packet based on the either the source or destination IP address. By default, it assigns a mark value equal to the low-order 8 bits of the source address.

The syntax is as follows:

Default values are:

src and dst specify whether the mark is to be based on the source or destination address respectively. The selected address is first shifted right by shift, then LANDed with mask1 and then LORed with mask2. The shift argument is intended to be used primarily with IPv6 addresses.

Example:

IPMARK(src,0xff,0x10100)

Source IP address is 192.168.4.3 = 0xc0a80403

        0xc0a80403 >> 0         = 0xc0a80403
        0xc0a80403 LAND 0xFF    = 0x03
        0x03       LOR  0x10100 = 0x10103

        So the mark value is 0x10103 which corresponds to class id 1:103.

It is important to realize that, while class IDs are composed of a major and a minor value, the set of minor values must be unique. You must keep this in mind when deciding how to map IP addresses to class IDs. For example, suppose that your internal network is 192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6). Your first notion might be to use IPMARK(src,0xFF,0x10000) so as to produce class IDs 1:1 through 1:6. But 1:1 is the class ID of the base HTB class on interface 1. So you might chose instead to use IPMARK(src,0xFF,0x10100) as shown in the example above so as to avoid minor class 1.

The occurs option in /etc/shorewall/tcclasses causes the class definition to be replicated many times.

The synax is:

When occurs is used:

The class should not specify a MARK value. Any MARK value given is ignored with a warning. The RATE and CEIL parameters apply to each instance of the class. So the total RATE represented by an entry with occurs will be the listed RATE multiplied by number.

Example:

/etc/shorewall/tcdevices:

#INTERFACE IN-BANDWIDTH OUT-BANDWIDTH
eth0       100mbit      100mbit

/etc/shorewall/tcclasses:

#DEVICE   MARK RATE     CEIL PRIORITY    OPTIONS
eth0:101     - 1kbit 230kbit        4    occurs=6

The above defines 6 classes with class IDs 0x101-0x106. Each class has a guaranteed rate of 1kbit/second and a ceiling of 230kbit.

/etc/shoreall/mangle or /etc/shoreall/tcrules:

#ACTION                          SOURCE             DEST
IPMARK(src,0xff,0x10100):F       192.168.1.0/29     eth0

This facility also alters the way in which Shorewall generates a class number when none is given. Prior to the implementation of this facility, the class number was constructed by concatinating the MARK value with the either '1' or '10'. '10' was used when there were more than 10 devices defined in /etc/shorewall/tcdevices.

With this facility, a new method is added; class numbers are assigned sequentially beginning with 2. The WIDE_TC_MARKS option in shorewall.conf selects which construction to use. WIDE_TC_MARKS=No (the default) produces pre-Shorewall 4.4 behavior. WIDE_TC_MARKS=Yes (TC_BITS >= 14 in Shorewall 4.4.26 and later) produces the new behavior.

As you read the article, numbers seem to be introduced out of thin air. I'll try to shed some light on those.

There is very clear development of these numbers:

We then learn that the queuing latency can be reduced to 30ms if we use a two-part service curve whose first part is 400kbits/second. Where did those come from?

The final curious number is the latency for class 1:11 - 52.5ms. It is a consequence of everything that has gone before.

To acheive 400kbits/second with 1500-byte packets, 33.33 packets per second are required. So a packet from class 1:11 must be sent every 30 ms. As the article says, "...the maximum transmission delay of this class increases from 30ms to a total of 52.5 ms.". So we are looking for an additional 22.5 ms.

Assume that both class 1:11 and 1:12 transmit for 30 ms at 400kbits/second. That is a total of 800kbits/second for 30ms. So Class 1:11 is punished for the excess. How long is the punishment? The two classes sent 24,000 bits in 30ms; they are only allowed 0.030 * 500,000 = 15,000. So they are 9,000 bits over their quota. The amount of time required to transmit 9,000 bits at 400,000 bits/second is 22.5ms!.

While this file was created to allow shaping of traffic through an IFB, the file may be used for general traffic classification as well. The file is similar to shorewall-mangle(5) with the following key exceptions:

The last point warrants elaboration. When looking at traffic being shaped by an IFB, there are two cases to consider:

Beginning with Shorewall 4.4.15, both IPv4 and IPv6 rules can be defined in this file. See shorewall-tcfilters (5) for details.

Columns in the file are as follow. As in all Shorewall configuration files, a hyphen ("-") may be used to indicate that no value is supplied in the column.

Example:

I've used this configuration on my own firewall. The IFB portion is more for test purposes rather than to serve any well-reasoned QOS strategy.

/etc/shorewall/init:

qt modprobe ifb numifbs=1
qt ip link set dev ifb0 up

/etc/shorewall/interfaces:

#ZONE          INTERFACE         BROADCAST
-              ifb0

/etc/shorewall/tcdevices:

#INTERFACE      IN-BANDWITH     OUT-BANDWIDTH   OPTIONS         REDIRECTED
#                                                               INTERFACES
1:eth0          -               384kbit         classify
2:ifb0          -               1300kbit        -               eth0

/etc/shorewall/tcclasses:

#INTERFACE      MARK    RATE            CEIL            PRIORITY        OPTIONS
1:110           -       5*full/10       full            1               tcp-ack,tos-minimize-delay
1:120           -       2*full/10       6*full/10       2               default
1:130           -       2*full/10       6*full/10       3
2:110           -       5*full/10       full            1               tcp-ack,tos-minimize-delay
2:120           -       2*full/10       6*full/10       2               default
2:130           -       2*full/10       6*full/10       3

/etc/shorewall/tcfilters:

#INTERFACE:     SOURCE          DEST            PROTO   DEST    SOURCE
#CLASS                                                  PORT(S) PORT(S)
#
#                                  OUTGOING TRAFFIC
#
1:130           206.124.146.178 -               tcp     -       49441,49442    #BITTORRENT on wookie
1:110           206.124.146.178                                                #wookie
1:110           206.124.146.179                                                #SNAT of internal systems
1:110           206.124.146.180                                                #Work Laptop
1:110           -               -               icmp    echo-request,echo-reply
1:110           -               -               icmp    echo-reply
1:130           206.124.146.177 -               tcp     -       873,25         #Bulk Traffic
#
#                                   INCOMING TRAFFIC
#
2:110           -               206.124.146.178                          #Wookie
2:110           -               206.124.146.179                          #SNAT Responses
2:110           -               206.124.146.180                          #Work Laptop
2:130           -               206.124.146.177 tcp     25               #Incoming Email.

You can examine the installed filters with the shorewall show filters command. What follows shows the output for eth0 with the filters shown above. Bold font are comments explaining the rules.

gateway:~ # shorewall-lite show filters
Shorewall Lite 4.1.6 Classifiers at gateway - Fri Mar 21 08:06:47 PDT 2008

Device eth1:

Device eth2:

Device eth0:
filter parent 1: protocol ip pref 10 u32 
filter parent 1: protocol ip pref 10 u32 fh 3: ht divisor 1   <========= Start of table 3. parses TCP header

filter parent 1: protocol ip pref 10 u32 fh 3::800 order 2048 key ht 3 bkt 0 flowid 1:130  (rule hit 102 success 0)
  match 03690000/ffff0000 at nexthdr+0 (success 0 )           <========= SOURCE PORT 873 goes to class 1:130

filter parent 1: protocol ip pref 10 u32 fh 2: ht divisor 1   <========= Start of table 2. parses ICMP header

filter parent 1: protocol ip pref 10 u32 fh 2::800 order 2048 key ht 2 bkt 0 flowid 1:110  (rule hit 0 success 0)
  match 08000000/ff000000 at nexthdr+0 (success 0 )           <========= ICMP Type 8 goes to class 1:110

filter parent 1: protocol ip pref 10 u32 fh 2::801 order 2049 key ht 2 bkt 0 flowid 1:110  (rule hit 0 success 0)
  match 00000000/ff000000 at nexthdr+0 (success 0 )           <========= ICMP Type 0 goes to class 1:110

filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1   <========= Start of table 1. parses TCP header

filter parent 1: protocol ip pref 10 u32 fh 1::800 order 2048 key ht 1 bkt 0 flowid 1:130  (rule hit 0 success 0)
  match c1210000/ffff0000 at nexthdr+0 (success 0 )           <========= SOURCE PORT 49441 goes to class 1:130

filter parent 1: protocol ip pref 10 u32 fh 1::801 order 2049 key ht 1 bkt 0 flowid 1:130  (rule hit 0 success 0)
  match c1220000/ffff0000 at nexthdr+0 (success 0 )           <========= SOURCE PORT 49442 goes to class 1:130

filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 <========= Start of Table 800. Packets start here!

   =============== The following 2 rules are generated by the class definition in /etc/shorewall/classes ==================

filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:110  (rule hit 2204 success 138)
  match 00060000/00ff0000 at 8 (success 396 )                 <========= TCP    
  match 05000000/0f00ffc0 at 0 (success 250 )                 <========= Header length 20 and Packet Length < 64 
  match 00100000/00ff0000 at 32 (success 138 )                <========= ACK

filter parent 1: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:110  (rule hit 2066 success 0)
  match 00100000/00100000 at 0 (success 0 )                  <========= Minimize-delay goes to class 1:110

                        =============== Jump to Table 1 if the matches are met ==================
 
filter parent 1: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 bkt 0 link 1:  (rule hit 2066 success 0)
  match ce7c92b2/ffffffff at 12 (success 1039 )              <========= SOURCE 206.124.146.178          
  match 00060000/00ff0000 at 8 (success 0 )                  <========= PROTO TCP
    offset 0f00>>6 at 0  eat 

filter parent 1: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:110  (rule hit 2066 success 1039)
  match ce7c92b2/ffffffff at 12 (success 1039 )               <========= SOURCE 206.124.146.178 goes to class 1:110

filter parent 1: protocol ip pref 10 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:110  (rule hit 1027 success 132)
  match ce7c92b3/ffffffff at 12 (success 132 )                <========= SOURCE 206.124.146.179 goes to class 1:110

filter parent 1: protocol ip pref 10 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:110  (rule hit 895 success 603)
  match ce7c92b4/ffffffff at 12 (success 603 )                <========= SOURCE 206.124.146.180 goes to class 1:110

                        =============== Jump to Table 2 if the matches are met ==================

filter parent 1: protocol ip pref 10 u32 fh 800::806 order 2054 key ht 800 bkt 0 link 2:  (rule hit 292 success 0)
  match 00010000/00ff0000 at 8 (success 0 )                   <========= PROTO ICMP 
    offset 0f00>>6 at 0  eat

                        =============== Jump to Table 3 if the matches are met ==================
 
filter parent 1: protocol ip pref 10 u32 fh 800::807 order 2055 key ht 800 bkt 0 link 3:  (rule hit 292 success 0)
  match ce7c92b1/ffffffff at 12 (success 265 )                <========= SOURCE 206.124.146.177
  match 00060000/00ff0000 at 8 (success 102 )                 <========= PROTO TCP
    offset 0f00>>6 at 0  eat 

If you prefer your own tcstart file, just install it in /etc/shorewall/tcstart.

In your tcstart script, 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.

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: