Control

The control page is used to manage the SmoothTraffic sub-system, including: starting and stopping the service; setting the traffic scheme; and setting the external connection speeds.

To ensure that the SmoothTraffic sub-system is automatically started each time the SmoothWall system is rebooted, select the Start Traffic sub-system automatically tick-box control.

The Manual control region displays the current status of the SmoothTraffic sub-system and provides the following controls:

• Restart - Used to stop and restart the SmoothTraffic sub-system, with all outstanding configuration changes applied.
• Stop - Used to stop the SmoothTraffic sub-system and all bandwidth management activity.
• Refresh - Used to re-display the current status of the SmoothTraffic sub-system.

The Available schemes region lists the SmoothTraffic schemes that are available for use. A scheme is simply a set of traffic categories with rules that describe how to prioritise traffic. Such rules typically consist of a minimum bandwidth, and a ceiling.

To display an information page about a particular traffic scheme, simply click its name in this region.

The Scheme region allows you to set the scheme used by SmoothTraffic for bandwidth management. The following controls are provided:

• Current SmoothTraffic scheme - Used to set the scheme used by SmoothTraffic for bandwidth management. Once you have selected a new scheme (and saved your settings) you will be required to set the classification of unassigned traffic. This is because different schemes utilise different categories, so it is not always possible to predetermine a sensible choice for unassigned traffic prior to loading the scheme.
• Optional scheme parameter - Used to set any optional scheme parameters that may be defined in the current scheme. The scheme description explains in detail the parameters for each scheme, and the allowable range of values. The Default scheme has no parameter - others like Split and Multiway do.
• Unassigned traffic going to category - Used to set the traffic category for any traffic that remains unclassified by any of the user-defined rules for the scheme. There are two main strategies for managing unclassified traffic. The first is to treat much of your traffic as unclassified, and merely raise or lower the priority of specific traffic. In this case, it is clearly advisable to give unclassified traffic a "normal" tag. Alternatively, it is possible that you intend to classify the vast majority of traffic, leaving only exceptional or unwanted traffic without a classification. A "slow" tag is the usual choice for unclassified traffic using this strategy.
• Log unassigned traffic - Used to enable logging for every packet that has not been classified explicitly by SmoothTraffic. All log entries are made to the kernel error log. This option can generate large amounts of data, and rapidly consume resources - processing power, disk space, etc. so it should be used only with care. If you expect that very little traffic will be unclassified, it may be beneficial to select this control. Alternatively, this feature can be used for a short period of time to monitor unclassified traffic closely, perhaps with a view to classifying it by writing rules that match it.

Once a scheme has been chosen and appropriate parameters have been entered, you should proceed to define rules to classify the traffic passing through the system.

You can view the log from the logs -> System logs -> kernel menu. Example from log:

The string "[tr]_normal__" marks a line in the log as SmoothTraffic unclassified traffic (which is being treated as normal in this case). The rest of the log entry includes the packet's source IP/port and destination IP/port amongst other things - enough information to write a rule to match it and hence assign a traffic class.

This region is used to set the speeds for the default external interface and all internal interfaces. It is important to set these speeds accurately - set them too high and your traffic management will have much reduced effect, too low, and your performance will suffer.

The speed of the external interface is that of your Internet connection. ADSL and other asymmetric services have different download and upload speeds, be sure to set these accordingly. A typical basic UK ADSL is 512kbit/s download and 256kbit/ upload. The entry level SmoothTraffic product is licensed for up to 1024kbit/s upload/download. If your Internet connection is faster than this you will have to purchase a licence for your required speed.

If the usable speed of an interface is lower than the speed stated here then some of the traffic control capabilities of SmoothTraffic will be compromised, simply because it will not be the slowest point of the connection. The purpose of traffic control is to be the "choke point" so the packets' priority can be decided here rather than somewhere "upstream".

• Download - Used to set the download speed for the default external connection.
• Upload - Used to set the upload speed for the default external connection.
• Upload & Download - Used to set upload / download speeds for an internal interface.
• User defined - Used to specify a custom speed for an internal or external interface.
  
  • bit/s - Used to set the user defined speed value in bits per second.
  • Kbit/s - Used to set the user defined speed value in Kilobits per second.
  • Mbit/s - Used to set the user defined speed value in Megabits per second.
  • byte/s - Used to set the user defined speed value in bytes per second.
  • Kbyte/s - Used to set the user defined speed value in Kilobytes per second.
  • Mbyte/s - Used to set the user defined speed value in Megabytes per second.

If SmoothTraffic is not handling traffic in the way you expect, try lowering the stated speed of the external interface slightly. ADSL in particular is a contended service, so if your neighbours are generating a great deal of traffic you may not get the advertised bandwidth of your connection.

If the interface you are setting the speed on is a VPN interface you will have to take into account any non VPN traffic that may be using the same physical interface. You can either do this by just manually lowering the speed of the "External IPSec" interface or by using the Split scheme and reserving bandwidth - e.g. use 50% of your bandwidth for the VPN.

In this case, set the VPN speeds to half the speeds that you have used for the physical interface and make a rule to send all VPN encrypted traffic (protocols 50 and 51) into one Split with all non VPN traffic into the other. This will guarantee that VPN traffic will have a known and therefore manageable bandwidth but at the expense of only 50% of possible bandwidth ever available to it.

Core Rules

The core page is used to create Core Rules - rules that associate traffic categories (from the currently selected traffic scheme) to particular types of network traffic.

A Core Rule defines a type of traffic (by protocol, service and direction) and how it should be treated by the currently selected traffic scheme.

Core Rules can be applied by SmoothTraffic in two ways:

• Globally - If the Core Rule is enabled, it can be applied to all Internet traffic.
• As part of an Address Rule - If the core rule is not applied globally, it can be selectively applied as part of an Address Rule.

Applying a Core Rule as part of an Address Rule is used when you wish to selectively apply the core rule to particular network hosts.

This region displays a reminder of the currently selected traffic scheme.

A Core Rule consists of a protocol, a service, and a direction. For some protocols, service and direction may not apply.

The configuration controls located in the Add core rule region are used to create new Core Rules. When editing a Core Rule, the title of this region reads "Edit core rule".

• Rule name - Used to set a name for this Core Rule. Rule names may contain only alpha-numeric characters and the underscore ("_") character. The default name for a newly added rule is "Unnamed" - you should consider changing this to a more descriptive name.
• Protocol - Used to choose a protocol that this Core Rule will be applied to. Note that for some protocols, the Service and Direction fields may not apply.
  
  • UDP - Apply this Core Rule to UDP traffic.
  • TCP - Apply this Core Rule to TCP traffic.
  • TCP & UDP - Apply this Core Rule to TCP & UDP traffic.
  • ICMP (1) - Apply this Core Rule to ICMP traffic (Ping etc.)*
  • GRE (47) - Apply this Core Rule to L2TP VPN traffic.*
  • ESP (50) - Apply this Core Rule to ESP / IPSec VPN traffic.*
  • AH (51) - Apply this Core Rule to AH / IPSec VPN traffic.*
  • All - Apply this Core Rule across all protocols.*
• Service - Used to select a well-known service that this Core Rule applies to. To apply a Core Rule against a user defined service, choose the "User defined" option and enter a numeric port value in the User defined text field. Port ranges can be entered using the following format:
  
  • 6666:6668
• User defined - Used to define a numeric port number that this Core Rule will apply to when "User defined" is selected from the Service drop-down menu.
• Service direction - Used to specify whether this Core Rule applies to incoming or outgoing traffic. This refers to the direction in which the traffic was initiated - for example, "Outgoing" HTTP traffic on port 80 means an outgoing request, such as someone on the local network browsing the web. "Incoming" HTTP would refer to web servers on your local networks. Careful consideration should be given when choosing this setting - "Outgoing" does not necessarily imply that the majority of traffic will go "upstream" - for example, outgoing requests from a web browsing end-user will usually generate more incoming traffic (from the remote web server's response) than the initial outgoing traffic.
• Traffic category - Used to select the traffic category (from the currently selected traffic scheme) that will be applied to the traffic defined by this Core Rule.
• Logged - Used to specify that log entries should be generated for any traffic affected by this rule.
• Apply globally - Used to activate this Core Rule and apply it to all network hosts. If this tick-box is not selected, the Core Rule must be selectively applied by creating an Address Rule that uses it - otherwise the Core Rule will not be used at all. For backward compatibility, the Internal IP and External IP fields of the Address Rule can be left blank - this has the same effect as selecting this Apply globally tick-box.
• Comment - Used to enter a descriptive comment about this Core Rule.

Protocols marked: * - The Service and Service Direction fields will not apply if this protocol is selected.

If a web proxy is in use on the SmoothWall system (such as those provided by the SmoothProxy or SmoothGuardian modules), any rules that you create to manage web traffic (TCP, HTTP port 80 traffic) will have no effect.

The reason for this is that if a proxy is in operation, the flow of data will be from the user to the proxy to the intended destination. Since there is no direct forwarding of web requests, there is nothing that the Core Rules can work on. Creating such rules is harmless - if a proxy inside the network is used it will function normally, with its own rate limiting communication (if enabled) operating between the proxy and remote web sites.

In particular, SmoothGuardian has its own settings for limiting the speed of the proxy. For further information, see the help pages from the SmoothGuardian configuration pages.

The list of Core Rules that use traffic categories from the currently selected traffic profile are displayed in this region. Core Rules can be edited or deleted by "Marking" them and clicking the appropriate Remove or Edit button.

Note 1 - Core Rules that use traffic categories from other traffic schemes are hidden unless their traffic scheme is selected. Core Rules cannot be "lost".

Note 2 - Traffic schemes that use the same traffic categories "share" the same Core Rules. Any Core Rule that uses a traffic category that is named in the currently selected scheme will be visible, even if it was created when a different traffic scheme was active.

To edit a particular Core Rule, select it using the Mark tick-box control from the Current core rules region and click the Edit button.

If you edit a Core Rule and save it with a different name, a new Core Rule will be created, and the original rule will remain unchanged. This is useful if you want to make a lot of very similar rules quickly.

To remove one or more Core Rules, use the Mark tick-box controls from the Current core rules region and click the Remove button.

Note 1 - Once a rule is removed, it is permanently erased - there is no way to "undelete" it.

Note 2 - Current rule sets are saved as part of your "backup floppy disk" or "backup floppy image file" so backup your system up before and after doing any major work on rule-sets.

Note 3 - It is not possible to remove a Core Rule if it is in use by any Address Rule - the Address Rule must be removed first.

The Restart region will appear if any changes have been made to the Core Rules since the current traffic scheme was last activated. Click the Restart button to restart the SmoothTraffic sub-system, and activate the current set of rules configured in SmoothTraffic.

Address Rules

The address page is used to create Address Rules - rules that are used to apply traffic shaping Core Rules to network traffic originating from particular internal or external network sources.

An Address Rule is used to define:

• The origin of network traffic that should be considered for bandwidth management by SmoothTraffic.
• The specific type of network traffic that should be managed by SmoothTraffic.
• The traffic shaping behaviour that should be applied by SmoothTraffic.

Network traffic will be subject to traffic shaping by a particular Address Rule if the following conditions are all true:

• The traffic flows between the Internal IP and External IP addresses specified in the Address Rule.
• The traffic uses the protocol that is stated in the Core Rule (selected within the Address Rule).
• The traffic is destined for the service (or port range) stated in the Core Rule (selected within the Address Rule).
• The traffic flows in the same direction (incoming or outgoing) as stated in the Core Rule (selected within the Address Rule).

This region displays a reminder of the currently selected traffic scheme.

An Address Rule consists of a pair of IP addresses (internal and external) and a Core Rule. It is not possible to add an Address Rule unless at least one Core Rule has been created for the currently selected traffic scheme. The Address Rule allows you to optionally limit a Core Rule's application by providing various parameters.

The configuration controls located in the Add address rule region are used to create new Address Rules. When editing an Address Rule, the title of this region reads "Edit address rule".

• Rule name - Used to set a name for this Address Rule. Rule names may contain only alpha-numeric characters and the underscore ("_") character. The default name for a newly added rule is "Unnamed" - you should consider changing this to a more descriptive name.
• Core rule - Used to specify the Core Rule that will match a particular type of network traffic for this Address Rule.
• Internal IP - Used to specify the internal IP address, IP address range or subnet that the underlying Core Rule will be applied to. The following formats can be used:
  
  • 192.168.10.1 (a single IP address)
  • 192.168.10.1-192.168.20.50 (an IP address range)
  • 192.168.10.0/24 (an IP subnet)
  • 192.168.10.0/255.255.255.0 (an IP subnet)
• External IP - Used to specify the external IP address, IP address range or subnet that the underlying Core Rule will be applied to.
• Order - Used to choose the precedence of this Address Rules when matching packets. In most cases, the 'Default' order is fine - however, if data is being wrongly classified, manual specification may be necessary. For example, a general rule applied to all TCP traffic may be incorrectly taking precedence over a more specific rule for HTTP. Since traffic ceases to be checked after the first "match", HTTP traffic would be wrongly classified as plain TCP. To prevent this, raise the priority of the HTTP rule. An order of 1 denotes the highest priority, and will be matched first of all, down to Default being the lowest. Address Rules with the same priority may be matched in an arbitrary order.
• Logged - Used to specify that log entries should be generated for any traffic affected by this rule. Log entries will appear in the kernel error log every time a packet matches this Address Rule. This should be seen as a way to assist developing rules rather than something that is left enabled for long periods.
• Comment - Used to enter a descriptive comment about this Address Rule.
• Enabled - Used to activate this Address Rule. Bandwidth Management for this Address Rule will not be active until this tick-box is selected. This can be used to define rules that are not used all the time, but which can be quickly turned on or off when required.

Tip - The Internal IP and External IP addresses should be made as specific as possible. When Address Rules are not tied to specific addresses, certain protocols (for example, BitTorrent) may be wrongly classified. Without the benefit of an address to act as an anchor, some incoming and outgoing packets can look the same in their port usage, and so may get classified together - even if separate Core Rules are used for incoming and outgoing traffic.

The list of Address Rules that use Core Rules from the currently selected traffic profile are displayed in this region. Address Rules can be edited or deleted by "Marking" them and clicking the appropriate Remove or Edit button.

Note 1 - Any Address rules that use Core Rules that in turn use traffic categories not in the current traffic scheme will be hidden. They have not been lost - switching back to the previous scheme will restore them.

Note 2 - Address Rules can be "shared" by traffic schemes that in turn "share" the same Core Rules. If you have an Address Rule that you do not wish to use in the current scheme, it should be disabled. Editing an Address Rule

To edit a particular Address Rule, select it using the Mark tick-box control from the Current address rules region and click the Edit button.

If you edit an Address Rule and save it with a different name, a new Address Rule will be created, and the original rule will remain unchanged. This is useful if you want to make a lot of very similar rules quickly.

To remove one or more Address Rules, use the Mark tick-box controls from the Current address rules region and click the Remove button.

Note 1 - Once a rule is removed, it is permanently erased - there is no way to "undelete" it.

Note 2 - Current rule sets are saved as part of your "backup floppy disk" or "backup floppy image file" so backup your system up before and after doing any major work on rule-sets.

The Restart region will appear if any changes have been made to the Address Rules since the current traffic scheme was last activated. Click the Restart button to restart the SmoothTraffic sub-system, and activate the current set of rules configured in SmoothTraffic.

Statistics

The stats page displays a number of SmoothTraffic usage reports. These reports are also added to the reports sub-system, allowing SmoothTraffic statistics to be displayed on the Information | summary and Main | control configuration pages if required.

SmoothTraffic statistics are updated every minute. The following three tables of statistics are available:

• SmoothTraffic Rule Statistics - Statistics concerning data flowing through each user defined rule.
• SmoothTraffic Class Statistics - Statistics concerning data assigned to each traffic category "class" (tag) for the currently selected traffic scheme.
• Traffic Statistics - Statistics concerning whole interface traffic statistics.

Note 1 - Values are calculated in bytes, rounded up to K, M or Gbytes for display purposes. Thus they should only be considered as approximate.

Note 2 - SmoothTraffic statistics are not generally suitable for use as a billing guide. This is because SmoothTraffic can be configured in an almost endless number of ways, and to achieve a comprehensive and realistic mapping between organisational structure and network traffic is an extremely complex task.

For detailed information about each report, refer to the three sections below.

SmoothTraffic Rule Statistics concern data flowing through the currently active Core and Address Rules. Data is displayed for each rule, by interface, for the following current and previous periods:

• Current hour
• Current day
• Current week
• Current month
• Previous hour
• Yesterday
• Last week
• Last month

Note 1 - If the associated interface is external, the displayed data concerns outgoing (or upload) traffic.

Note 2 - If the interface is internal, the displayed data concerns incoming (or download) traffic.

Note 3 - Usage bars for each rule may be displayed at the top of the report, providing an easy means of determining the proportion of data passing through the rule in the last sample period. The size of the bar represents an approximate share of the available upload / download bandwidth. This enables you to see at a glance which rules account for most network use.

Class statistics are gathered for all classes (traffic category "classes" or "tags") used in the currently selected scheme. The various Core and Address Rules that are currently active can tag data into the same class - and bandwidth sharing is performed on a class basis (not directly by rules). It is therefore useful to know which classes are accumulating data.

SmoothTraffic Class Statistics concern data assigned to each traffic category class. Data is displayed for each class, by interface, for the following current and previous periods:

• Current hour
• Current day
• Current week
• Current month
• Previous hour
• Yesterday
• Last week
• Last month

The following current statistics are available:

• Current hour
• Current day
• Current week
• Current month
• Previous hour
• Yesterday
• Last week
• Last month

Note 1 - These statistics are available even if SmoothTraffic is not running.

Note 2 - These statistics are only for traffic that has been controlled. Traffic that enters the firewall and is not forwarded on anywhere is not counted, because traffic control can only be applied on outgoing interfaces. The main effect of this is that incoming data into the web proxy (or SmoothGuardian, if installed) is not counted. The webcache rule only covers outgoing data as only outgoing data can be traffic controlled. In most normal cases this is not a problem, since incoming data can be queued at the internal interfaces just as outgoing data gets queued at the external interfaces. However, in the case of the web cache, the incoming data ends up in the cache. When data does leave over the internal interfaces, it should be at full speed - users should not have to wait for data that is already stored in the cache.

Note 3 - It is not an error for the incoming traffic statistics to be considerably lower than the traffic stats in the information section if a web proxy is in operation.