From 1974e95454c9aab2d9d043d329ce761594b6cda1 Mon Sep 17 00:00:00 2001 From: judas_iscariote Date: Thu, 6 Oct 2005 23:29:16 +0000 Subject: [PATCH] merge arne bernin docs for TS git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2820 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/traffic_shaping.xml | 857 +++++++++++++++------------- 1 file changed, 476 insertions(+), 381 deletions(-) diff --git a/Shorewall-docs2/traffic_shaping.xml b/Shorewall-docs2/traffic_shaping.xml index d4f8048bd..783b8e6bd 100644 --- a/Shorewall-docs2/traffic_shaping.xml +++ b/Shorewall-docs2/traffic_shaping.xml @@ -13,108 +13,507 @@ Eastep + + Arne + + Bernin - 2005-09-12 + 2005-10-07 - 2001-2005 - + 2001-2004 Thomas M. Eastep - + + 2005 + Arne Bernin + Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled - GNU Free Documentation - License. + GNU Free Documentation License.
Introduction - Shorewall does not do any type of Traffic Shaping/Bandwidth - management itself but it does contain some facilities to intergrate with - traffic shaping/control solutions. In order to use traffic shaping with - Shorewall, it is essential that you get a copy of the Linux Advanced Routing and Shaping - HOWTO, version 0.3.0 or later or The Traffic Control - HOWTO. It is also necessary to be running Linux Kernel 2.4.18 or - later. Shorewall traffic shaping support consists of the following: + + Starting with Version 2.5.5, shorewall has builtin support for traffic shaping + and control. Before this version, the support was quite limited. You were able + to use your own tcstart script (and you still are), but besides the tcrules file + it was not possible to define classes or queueing discplines inside the shorewall + config files. + + The support for traffic shaping and control still does not cover all + options available (and especially all algorithms that can be used to queue traffic) + for the Linux kernel but it should fit most needs. + If you are using your own script for traffic control und you still want to use it rather + the builtin support in the future, you will find information on how to do this, + later in this document. But for this to work, + you will also need to enable traffic shaping in the kernel and shorewall as + covered by the next sections. + +
+
+ Linux traffic shaping and control + + This section gives a brief introduction of how controlling traffic with + the linux kernel works. Although this might be enough for configuring it in + the shorewall configuration files, it still might be a good idea to take a + deeper look into the Linux Advanced Routing and Shaping HOWTO. + At the time of writing this, the current version is 1.0.0. + + Since kernel 2.2 Linux has extensive support for controlling traffic. You can define different + algorithms that are used to queue the traffic before it leaves an interface. The standard one is called + pfifo and is (as the name suggests) of the type First In First out. This means, that it does not shape + anything, if you have a connection that eats up all your bandwidth, this qeueing algorithm will not + stop it from doing so. + For shorewall traffic shaping we use two algorithms, one is called HTB (Hierarchical + Token Bucket) and SFQ (Stochastic Fairness Queuing). SFQ is easy to explain: it just tries to track + your connections (tcp or udp streams) and balances the traffic between them. This normaly works ok. + HTB allows you to define a set of classes, and you can put the traffic you want into these classes. + You can define minimum and maximum bandwitdh settings for those classes and order the hierachically (the less + priorized classes only get bandwitdth if the more important have what they need). + Shorewall builtin traffic shaping allows you to define these classes (and their bandwidth limits), and it + uses SFW inside these classes to make sure, that different data streams are handled equally. + + You can only shape outgoing traffic. The reason for this is simple, + the packets were already received by your network card before you can + decide what to do with them. So the only choice would be to drop them + which does normally makes no sense (since you received the packet already, + it went through the possible bottleneck (the incoming connection). + The next possible bottleneck might come if the packet leaves on another + interface, so this will be the place where queuing might occur. So, + defining queues for incoming packages is not very useful, you just want + to have it forwarded to the outgoing interface as fast as possible. + + There is one exception, though. Limiting incoming traffic to a value + a bit slower than your actual line speed will avoid queuing on the other + end of that connection. This is mostly useful if you don't have access + to traffic control on the other side and if this other side has a + faster network connection than you do (the line speed between the systems + is the bottleneck, e.g. a DSL connection to you providers router). + So, if you drop packages that are coming in too fast, the underlaying + protocol might recognize this and slow down the connection. TCP has a + builtin mechanism for this, UDP has not (but the protocol over UDP might + recognize it , if there is any). + + The reason why qeueing is bad in these cases is, that you might have + packets which need to be priorized over others, e.g. VoIP or ssh. For + this type of connections it is important that packets arrive in a certain + amount of time. For others like http downloads, it does not really + matter if it takes a few seconds more. + If you have a large queue on the other side and the router there does + not care about QoS or the QoS bits are not set properly, your + important packets will go into the same queue as your less timecritical + download packets which will result in a large delay. + +
+ +
+ + Linux Kernel Configuration + + You will need at least kernel 2.4.18 for this to work, + please take a look at the following screenshot for what settings you need + to enable. For builtin support, you need the HTB scheduler, the PRIO + pseudoscheduler and SFQ queue. The other scheduler or queue algorithms are + not needed. + + This screen shot show how I've configured QoS in my Kernel: +
+ + + +
+ Enable TC support in shorewall + + You need this support whether you use the builtin support or + whether you provide your own tcstart script. + + To enable general support for traffic shaping and control in shorewall, + you have to do the following: - A new TC_ENABLED parameter in - /etc/shorewall.conf. + Set TC_ENABLED to Yes in /etc/shorewall/shorewall.conf - A new CLEAR_TC 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. + Setting CLEAR_TC parameter in + /etc/shorewall/shorewall.conf to Yes will clear the traffic shaping + configuration during Shorewall [re]start and Shorewall stop. + This is normally what you want when using the builtin support (and + also if you use your own tcstart script) - /etc/shorewall/tcrules - A file - where you can specify firewall marking of packets. The firewall mark - value may be used to classify packets for traffic - shaping/control. + The other steps that follow depend on whether you use your own script + or the builtin solution. They will be explained in the following sections. + + + + +
+ + +
+ Using builtin traffic shaping/control + + For defining bandwidths (for either devices or classes) please + use kbit or kbps(for Kilobytes per second) and make sure there + is NO space between the number and the unit (100kbit not 100 kbit). + You generally could use mbit or mbps or just Bytes, but i suggest + to use kbit, as values lether than 1 are not supported (NO 0.5mbit). + + To properly configure the settings for your devices you might + need to find out, the real up- and downstream rates you have. This + is especially the case, if you are using a DSL connection or one + of another type that do not have a guaranteed bandwidth. There + are several online tools that help you find out, try ..... + Don't trust the values your provider tells you for this, especially + measuring the real download speed is important! + + +
+ /etc/shorewall/tcrules + + 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. + + 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. You can cause packet marking to occur in the FORWARD chain + by using the MARK_IN_FORWARD_CHAIN option in shorewall.conf. + + Columns in the file are as follows: + + + + MARK - Specifies the mark value is to be assigned in case of a + match. This is an integer in the range 1-255. This value may be optionally + followed by + : and either F or P to + designate that the marking will occur in the FORWARD or PREROUTING + chains respectively. If this additional specification is omitted, the + chain used to mark packets will be determined by the setting of the + MARK_IN_FORWARD_CHAIN option in shorewall.conf. - /etc/shorewall/tcstart - 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 sample 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 - HTB (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. + 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 Shorewall Format and/or Subnets. - 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. - - You can generally use off-the-shelf traffic shaping scripts by - simply copying them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB - version) that way (i.e., I just copied wshaper.htb to - /etc/shorewall/tcstart and modified it according to the Wonder Shaper - README). WARNING: 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. + Examples eth0 192.168.2.4,192.168.1.0/24 - /etc/shorewall/tcclear - 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. + DEST -- Destination of the packet. Comma-separated list of IP + addresses and/or subnets. + + + + PROTO - Protocol - Must be the name of a protocol from + /etc/protocol, a number or all + + + + 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). + + + + 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. + + + + USER (Added in Shorewall version 1.4.10) - (Optional) This + column may only be non-empty if the SOURCE is the firewall itself. + When this column is non-empty, the rule applies only if the program + generating the output is running under the effective user and/or + group. It may contain : + + [<user name or number>]:[<group name or number>] + + The colon is optionnal when specifying only a user. + + Examples : john: / john / :users / john:users - 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. + + - To start traffic shaping when Shorewall starts: + 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. + + #MARK SOURCE DESTINATION PROTOCOL USER/GROUP +1 eth1 0.0.0.0/0 all +2 eth2 0.0.0.0/0 all +2 eth3 0.0.0.0/0 all +3 fw 0.0.0.0/0 all + + + + + + All GRE (protocol 47) packets not originating on the firewall and + destined for 155.186.235.151 should be marked with 12. + + #MARK SOURCE DESTINATION PROTOCOL USER/GROUP +12 0.0.0.0/0 155.182.235.151 47 + + + + + + All SSH packets originating in 192.168.1.0/24 and destined for + 155.186.235.151 should be marked with 22. + + #MARK SOURCE DESTINATION PROTOCOL USER/GROUP +22 192.168.1.0/24 155.182.235.151 tcp 22 + +
+ +
+ /etc/shorewall/tcdevices + + 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. + + + Columns in the file are as follows: + + + + INTERFACE - Name of interface. Each interface may be listed only + once in this file. You may NOT specify the name of an alias (e.g., eth0:0) + here; see FAQ #18. You man NOT specify + wildcards here, e.g. if you have multiple ppp interfaces, you need to put + them all in here! + + + IN-BANDWIDTH - The incoming Bandwidth of that interface. Please + note that you are not able to do traffic shaping on incoming traffic, + as the traffic is already received before you could do so. This Column allows + you to define the maximum traffic allowed for this interface in total, if + the rate is exceeded, the packets are dropped. + You want this mainly if you have a DSL or Cable Connection to avoid + queuing at your providers side. + + If you don't want any traffic to be dropped set this to a value faster + than your interface maximum rate. + + + OUT-BANDWIDTH - Specifiy the outgoing bandwidth of that interface. + This is the maximum speed your connection can handle. It is also the speed + you can refer as "full" if you define the tc classes. Outgoing traffic above + this rate will be dropped. + + + + + + + Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface + for this. The device has an outgoing bandwidth of 500kbit and an incoming bandwidth + of 6000kbit + + + #INTERFACE IN-BANDWITH OUT-BANDWIDTH +ppp0 6000kbit 500kbit + +
+
+ /etc/shorewall/tcclasses + + This file allows you to define the actual classes that are used to + split the outgoing traffic. + + + + INTERFACE - Name of interface. Each interface may be listed only + once in this file. You may NOT specify the name of an alias (e.g., eth0:0) + here; see FAQ #18. You man NOT specify + wildcards here, e.g. if you have multiple ppp interfaces, you need to put + them all in here! + + + + MARK - The mark value which is an integer in the range 1-255. You + define these marks in the tcrules file, marking the traffic you want + to go into the queueing classes defined in here. + You can use the same marks for different Interfaces. + + + + RATE - The minimum bandwidth this class should get, when the traffic load + rises. Please note that first the classes which equal or a lesser priority + value are served even if there are others that have a guaranteed bandwith + but a lower priority. + + + + CEIL - The maximum bandwidth this class is allowed to use when the link + is idle. Useful if you have traffic which can get full speed when more important + services (e.g. interactive like ssh) are not used. + You can use the value "full" in here for setting the maximum bandwidth + to the defined output bandwidth of that interface. + + + + PRIORITY - you have to define a priority for the class. packets + in a class with a higher priority (=lesser value) are handled before less priorized + onces. + You can just define the mark value here also, if you are increasing the mark values + with lesser priority. + + + + OPTIONS - A comma-separated list of options including the following: + + + default - this is the default class for that interface where all + traffic should go, that is not classified otherwise. + defining default for exactly one class per interface + is mandatory! + + + tos-<tosname> - this lets you define a filter for the + given <tosname> which lets you define a value of the Type Of Service + bits in the ip package which causes the package to go in this class. + Please note, that this filter overrides all mark settings, so if you define + a tos filter for a class all traffic having that mark will go in it + regardless of the mark on the package. + You can use the following for this option: + + tos-minimize-delay (16) + tos-maximize-throughput (8) + tos-maximize-reliability (4) + tos-minimize-cost (2) + tos-normal-service (0) + + + + + Each of this options is only valid for one class per + interface. + + + + tcp-ack - if defined causes an tc filter to be created that + puts all tcp ack packets on that interface that have an size of + <=64 Bytes to go in this class. This is useful for speeding up + downloads. Please note that the size of the ack packages is + limited to 64 bytes as some applications (p2p for example) use + to make every package an ack package which would cause them + all into here. We want only packages WITHOUT payload to match, + so the size limit. Bigger packets just take their normal way + into the classes. + + + This option is only valid for class per interface. + + + + + + + +
+
+ Real life examples +
+ Configuration to replace Wondershaper + + You are able to fully replace the wondershaper script by using the buitin + traffic control.You can find example configuration files at + "http://www1.shorewall.net/pub/shorewall/Samples/tc4shorewall/. Please note that they are just examples and need to be adjusted + to work for you. In this examples it is assumed that your interface for you internet connection is ppp0 + (for DSL) , if you use another connection type, you have to change it. You also need to change + the settings in the tcdevices.wondershaper file to reflect your line speed. The relevant lines of + the config files follow here. Please note that this is just an 1:1 replacement doing exactly what + wondershaper should do. You are free to change it... + + + tcclasses file + #INTERFACE MARK RATE CEIL PRIORITY OPTIONS +ppp0 1 full full 1 tcp-ack,tos-minimize-delay +ppp0 2 9*full/10 9*full/10 2 default +ppp0 3 8*full/10 8*full/10 2 + tcdevices file + #INTERFACE IN-BANDWITH OUT-BANDWIDTH +ppp0 5000kbit 500kbit + tcrules file + #MARK SOURCE DEST PROTO PORT(S) CLIENT USER +# PORT(S) +1:P 0.0.0.0/0 0.0.0.0/0 icmp echo-request +1:P 0.0.0.0/0 0.0.0.0/0 icmp echo-reply +# mark traffic which should have a lower priority with a 3: +# mldonkey +3 0.0.0.0/0 0.0.0.0/0 udp - 4666 + + + Wondershaper allows you to define a set of hosts and/or ports you want to classify as low priority. + To achieve this , you have to add these hosts to tcrules and set the mark to 3 (true if you use + the example configuration files). + + + Setting hosts to low priority + lets assume the following settings from you old wondershaper script (don't assume these + example values are really useful, they are only used for demonstrating): + +# low priority OUTGOING traffic - you can leave this blank if you want +# low priority source netmasks +NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28" + +# low priority destination netmasks +NOPRIOHOSTDST=60.0.0.0/24 + +# low priority source ports +NOPRIOPORTSRC="6662 6663" + +# low priority destination ports +NOPRIOPORTDST="6662 6663" + + This would result in the following additional settings to the tcrules file: + + +3 192.168.1.128/25 0.0.0.0/0 all +3 192.168.3.28 0.0.0.0/0 all +3 0.0.0.0/0 60.0.0.0/24 all +3 0.0.0.0/0 0.0.0.0/0 udp 6662,6663 +3 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663 +3 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663 +3 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663 +
+
+ +
+
+ Using your own tc script + +
+ Replacing builtin tcstart file + If you prefer your own tcstart file, just replace /etc/shorewall/tcstart with your own. + 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. @@ -137,7 +536,9 @@ /etc/shorewall/tcrules. - +
+
+ Traffic control outside shorewall 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 @@ -145,325 +546,19 @@ - Set TC_ENABLED=Yes and CLEAR_TC=No + Set TC_ENABLED=No and CLEAR_TC=No - Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear - scripts. - - - - If your tcstart script uses the fwmark - classifier, you can mark packets using entries in - /etc/shorewall/tcrules. - - -
- -
- Kernel Configuration - - This screen shot show how I've configured QoS in my Kernel: -
- -
- /etc/shorewall/tcrules - - 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. - - 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 - shorewall.conf. - - - Unlike entries in /etc/shorewall/rules, - evaluation of entries in /etc/shorewall/tcrules - continues after a match. So the final mark assigned to each packet is - determined by the last matching entry - in the /etc/shorewall/tcrules file. - - - - If you use providers (in /etc/shorewall/providers) with the - 'track' option then there are restrictions about how you can mark - packets involving those providers; see the Shorewall Routing documentation - for details. - - - Columns in the file are as follows: - - - - MARK - Specifies the mark value is to be assigned in case of a - match. This is an integer in the range 1-255. Beginning with Shorewall - version 1.3.14, this value may be optionally followed by - : and either F or P to - designate that the marking will occur in the FORWARD or PREROUTING - chains respectively. If this additional specification is omitted, the - chain used to mark packets will be determined by the setting of the - MARK_IN_FORWARD_CHAIN option in shorewall.conf. - - This possible values in this field were expanded in Shorewall - version 2.2.0: - - - - If your kernel and iptables include CONNMARK support then - you can also mark the connection rather than the packet - - - - The mark value may be optionally followed by "/" and a - mask value (used to determine those bits of the connection - mark to actually be set). - - - - The mark and optional mask are then followed by one - of: - C: Mark the connection in the chain determined by - the setting of MARK_IN_FORWARD_CHAIN - - CF: Mark the conneciton in the FORWARD - chain - - CP: Mark the connection in the PREROUTING - chain. - - - - - - - A classification of the form <major>:<minor> - where <major> and <minor> are integers. Corresponds to - the 'class' specification in these traffic shaping - modules: - - atm - - - cbq - - - dsmark - - - pfifo_fast - - - htb - - - prio - Classification always occurs in the POSTROUTING - chain. This feature requires Shorewall 2.2.0 and requires that - your kernel and iptables include CLASSIFY target support. - - - - RESTORE[/mask] -- restore the packet's mark from the - connection's mark using the supplied mask if any. Your kernel and - iptables must include CONNMARK support. As iabove, may be followed - by ":P" or ":F - - - - SAVE[/mask] -- save the packet's mark to the connection's - mark using the supplied mask if any. Your kernel and iptables must - include CONNMARK support. As above, may be followed by ":P" or - ":F - - - - CONTINUE -- don't process any more marking rules in the - table. As above, may be followed by ":P" or ":F". - - - - - - 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 Shorewall Format and/or Subnets. - - Examples eth0 - 192.168.2.4,192.168.1.0/24 - - Beginning with Shorewall version 2.2.2, "$FW" may be optionally - followed by a colon (":") and a host/net address or an address - range. - - - - DEST -- Destination of the packet. Comma-separated list of IP - addresses and/or subnets. - - - - PROTO - Protocol - Must be the name of a protocol from - /etc/protocol, "ipp2p", a number or "all". For "ipp2p", your kernel - and iptables must have ipp2p match support from Netfilter - Patch_o_matic_ng. - - - - 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). If the protocol is "ipp2p", then this - column is interpreted as an ipp2p option without the leading "--" - (default "ipp2p"). For a list of value ipp2p options, as root type - iptables -m ipp2p --help. - - - - CLIENT PORT(S) (Renamed SOURCE PORT(S) in Shorewall 2.2.0) - - (Optional) Source port(s). If omitted, any source port is acceptable. - Specified as a comma-separate list of port names, port numbers or port - ranges. - - - - USER (Added in Shorewall version 1.4.10) - (Optional) This - column may only be non-empty if the SOURCE is the firewall itself. - When this column is non-empty, the rule applies only if the program - generating the output is running under the effective user and/or - group. It may contain : - - [<user name or number>]:[<group name or - number>] - - The colon is optionnal when specifying only a user. - - Examples : john: / john / :users / john:users - - - - TEST (added in Shorewall version 2.2.0). Defines a test on the - existing packet or connection mark. The rule will match only if the - test returns true. Tests have the format - - [!]<value>[/<mask>][:C] - - where - - - ! Inverts the test (not equal) - - <value> Value of the packet or - connection mark. - - <mask> A mask to be applied to - the mark before testing - - :C Designates a connection mark. If omitted, the packet - mark's value is tested. - - - - - - - - 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. - - #MARK SOURCE DESTINATION PROTO PORT(S) SOURCE PORT(S) USER/GROUP TEST -1 eth1 0.0.0.0/0 all -2 eth2 0.0.0.0/0 all -2 eth3 0.0.0.0/0 all -3 $FW 0.0.0.0/0 all - - - - - - All GRE (protocol 47) packets not originating on the firewall and - destined for 155.186.235.151 should be marked with 12. - - #MARK SOURCE DESTINATION PROTO PORT(S) SOURCE PORT(S) USER/GROUP TEST -12 0.0.0.0/0 155.182.235.151 47 - - - - - - All SSH packets originating in 192.168.1.0/24 and destined for - 155.186.235.151 should be marked with 22. - - #MARK SOURCE DESTINATION PROTOCOL PORT(S) SOURCE PORT(S) USER/GROUP TEST -22 192.168.1.0/24 155.182.235.151 tcp 22 - -
- -
- My Current Setup - - I am currently using the HTB version of The Wonder Shaper (I just - copied wshaper.htb to /etc/shorewall/tcstart and modified it as shown in - the Wondershaper README). WonderShaper DOES NOT USE THE - /etc/shorewall/tcrules file. -
- -
- My Old Setup - - I have also run with the following set of hand-crafted rules in my - /etc/shorewall/tcstart file. - -
- run_tc qdisc add dev eth0 root handle 1: htb default 30 - -run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k -echo Added Top Level Class -- rate 384kbit - -run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1 -run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0 -run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit ceil 384kbit burst 15k quantum 1500 prio 1 -echo Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit - -run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5 -run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10 -run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5 -echo Enabled PFIFO on Second Level Classes - -run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10 -run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20 -run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30 -echo Defined fwmark filters - -
- - My tcrules file that went with this tcstart file is shown in Example - 1 above. When I was using these rules: - - - - I wanted to allow up to 140kbits/second for traffic outbound - from my DMZ (eth1 -- 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). - - - - My laptop (which at that time connected via eth3) and local - systems (eth2) could use up to 224kbits/second. - - - - My firewall could use up to 20kbits/second. - + If your script uses the fwmark + classifier, you can mark packets using entries in + /etc/shorewall/tcrules. But you have to set TC_ENABLED=Yes. This + is normally ok, if your tcdevices and tcclasses file does not + contain entries. + - Once www.shorewall.net was moved off-site, I no longer needed these - shaping rules and The Wonder Shaper does all that I now require. +
+
- \ No newline at end of file +