holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Add IN-BANDWIDTH setting advice to Traffic Shaping Doc

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3598 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-02-27 15:54:05 +00:00
parent d217e616a8
commit e718ffabcf
2 changed files with 12 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Shorewall/releasenotes.txt
View File

@ -42,7 +42,9 @@ None.
Migration Considerations: Migration Considerations:
1) A number of macros have been split into two. The macros affected are: 1) A number of macros have been split into two. The macros affected are:
IMAP LDAP NNTP POP3 SMTP IMAP LDAP NNTP POP3 SMTP
Each of these macros now handles only traffic on the native (plaintext) Each of these macros now handles only traffic on the native (plaintext)
port. There is a corresponding macro with S added to the end of the port. There is a corresponding macro with S added to the end of the
name for the SSL version of the same protocol. Thus each macro results name for the SSL version of the same protocol. Thus each macro results
@ -64,7 +66,7 @@ Migration Considerations:
DNAT Z1!Z2 loc:192.168.1.4 ... DNAT Z1!Z2 loc:192.168.1.4 ...
That syntax has never worked correctly when Z2 is a dynamic zone. That feature has never worked correctly when Z2 is a dynamic zone.
Furthermore, now that Shorewall supports exclusion lists, the capability Furthermore, now that Shorewall supports exclusion lists, the capability
is redundant since the above rule can now be written in the form: is redundant since the above rule can now be written in the form:

10
docs/traffic_shaping.xml
View File

@ -21,7 +21,7 @@
</author> </author>
</authorgroup> </authorgroup>
<pubdate>2006-01-04</pubdate> <pubdate>2006-02-27</pubdate>
<copyright> <copyright>
<year>2001-2006</year> <year>2001-2006</year>
@ -266,6 +266,14 @@
to avoid queuing at your providers side. If you don't want any 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 traffic to be dropped set this to a value faster than your interface
maximum rate.</para> maximum rate.</para>
<para>To determine the optimum value for this setting, we recommend
that you start by setting it significantly below your measured
download bandwidth (20% or so). While downloading, measure the
<emphasis>ping</emphasis> response time from the firewall to the
upstream router as you gradually increase the setting.The optimal
setting is at the point beyond which the <emphasis>ping</emphasis>
time increases sharply as you increase the setting.</para>
</listitem> </listitem>
<listitem> <listitem>