diff --git a/Shorewall-docs2/traffic_shaping.xml b/Shorewall-docs2/traffic_shaping.xml index 783b8e6bd..98cae9f88 100644 --- a/Shorewall-docs2/traffic_shaping.xml +++ b/Shorewall-docs2/traffic_shaping.xml @@ -13,454 +13,482 @@ Eastep - - Arne - Bernin + + Arne + + Bernin + - 2005-10-07 + 2005-10-08 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 - - 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. + 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. + 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 and 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. + 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). - 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. + 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. -
- -
- - 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: + 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 + Enable TC support in Shorewall - You need this support whether you use the builtin support or - whether you provide your own tcstart script. + 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: + To enable the builtin traffic shaping and control in Shorewall, you + have to do the following: - Set TC_ENABLED to Yes in /etc/shorewall/shorewall.conf + Set TC_ENABLED to No in + /etc/shorewall/shorewall.conf. While that seems a bit illogical, it is + done for compatibility with previous releases where TC_ENABLED=Yes + causes Shorewall to look for an external tcstart file (See a later section for details). 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/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) - 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. + 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 + 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). - 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. + 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! - 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. +
+ /etc/shorewall/tcrules - Columns in the file are as follows: + 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. - - - 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. - + 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. - - 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. + Columns in the file are as follows: - Examples eth0 192.168.2.4,192.168.1.0/24 - + + + 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. + - - DEST -- Destination of the packet. Comma-separated list of IP - addresses and/or subnets. - + + 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. - - PROTO - Protocol - Must be the name of a protocol from - /etc/protocol, a number or all - + Examples eth0 192.168.2.4,192.168.1.0/24 + - - 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). - + + DEST -- Destination of the packet. Comma-separated list of IP + addresses and/or subnets. + - - 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. - + + PROTO - Protocol - Must be the name of a protocol from + /etc/protocol, a number or all + - - 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 : + + 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). + - [<user name or number>]:[<group name or number>] + + 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. + - The colon is optionnal when specifying only a user. + + 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 : - Examples : john: / john / :users / john:users - - + [<user name or number>]:[<group name or + number>] - - + The colon is optionnal when specifying only a user. - 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. + Examples : john: / john / :users / john:users + + - #MARK SOURCE DESTINATION PROTOCOL USER/GROUP + + + + 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. + 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 + #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. + 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 + #MARK SOURCE DESTINATION PROTOCOL USER/GROUP 22 192.168.1.0/24 155.182.235.151 tcp 22 - -
+ +
-
- /etc/shorewall/tcdevices +
+ /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. - + 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: + 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. + + + 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! + - 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. - - + + 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 + 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. +
+ /etc/shorewall/tcclasses - - - 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. - + This file allows you to define the actual classes that are used to + split the outgoing traffic. - - 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: + + + 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! + - tos-minimize-delay (16) - tos-maximize-throughput (8) - tos-maximize-reliability (4) - tos-minimize-cost (2) - tos-normal-service (0) - + + 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. + - 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. - - - - - - + + 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 +
+ 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 + + tcdevices file + + #INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 5000kbit 500kbit - tcrules file - #MARK SOURCE DEST PROTO PORT(S) CLIENT USER + + 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 @@ -468,16 +496,18 @@ ppp0 5000kbit 500kbit # 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). - + 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): - + 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" @@ -491,9 +521,11 @@ NOPRIOPORTSRC="6662 6663" # low priority destination ports NOPRIOPORTDST="6662 6663" - This would result in the following additional settings to the tcrules file: - + 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 @@ -503,62 +535,63 @@ NOPRIOPORTDST="6662 6663" 3 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663
+
-
- Using your own tc script + 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. - - - Set TC_ENABLED=Yes and CLEAR_TC=Yes - + If you prefer your own tcstart file, just install it in + /etc/shorewall/tcstart. - - Supply an /etc/shorewall/tcstart script to configure your - traffic shaping rules. - + 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. - - Optionally supply an /etc/shorewall/tcclear script to stop - traffic shaping. That is usually unnecessary. - + + + Set TC_ENABLED=Yes and CLEAR_TC=Yes + - - If your tcstart script uses the fwmark - classifier, you can mark packets using entries in - /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 - not be covered here. You then should: + + Supply an /etc/shorewall/tcstart script to configure your + traffic shaping rules. + - - - Set TC_ENABLED=No and CLEAR_TC=No - - - - 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. - - + + Optionally supply an /etc/shorewall/tcclear script to stop + traffic shaping. That is usually unnecessary. + + + If your tcstart script uses the fwmark + classifier, you can mark packets using entries in + /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 not be covered here. You then + should: + + + + Set TC_ENABLED=No and CLEAR_TC=No + + + + If your script uses the fwmark classifier, you + can mark packets using entries in /etc/shorewall/tcrules. + + +
- + \ No newline at end of file