This section looks at the key principles of setting up traffic shaping and recommendations to follow when setting it up.
The following list summarizes the key principles involved in traffic shaping:
The base object for traffic management is a Pipe object.
Each pipe has a maximum bandwidth limit assigned to it. This is the capacity of the pipe.
A single pipe should handle traffic in only one direction (although 2 way pipes are allowed). Normally, a traffic flow will have a different pipe for each direction.
A TrafficProfile object defines which Pipe object (or objects) are associated with its forward and return traffic flows.
Pipes can be chained by specifying a list in the TrafficProfile object so that one pipe's traffic feeds into another pipe.
Enable traffic shaping by associating a TrafficProfile object with a TrafficShapingRule or an IPRule object.
Specific traffic types can be assigned a priority within a pipe. There are 8 precedence levels, from 0 (the lowest) to 7 (the highest).
Priorities can be assigned a maximum limit which is also a guarantee. Traffic that exceeds this will be sent at the minimum precedence which is known as the best-effort precedence.
At the best-effort precedence all packets are treated on a "first come, first forwarded" basis.
Within a pipe, traffic can also be separated on a Group basis. For example, by source IP address. Each user in a group (for example, each source IP address) can be given a maximum limit and precedences within a group can be given a limit/guarantee.
A pipe bandwidth limit need not be specified if the group members have a maximum limit assigned.
Dynamic Balancing can be enabled to specify that all users in a group get a fair and equal amount of bandwidth.
The Importance of a Pipe Limit
Traffic shaping only comes into effect when a pipe is full. That is to say, it is passing as much traffic as the total limit allows. If a 500 Kbps pipe is carrying 400 Kbps of low priority traffic and 90 Kbps of high priority traffic then there is 10 Kbps of bandwidth left and there is no reason to throttle back anything. It is therefore important to specify a total limit for a pipe so that it knows what its capacity is and the precedence mechanism is totally dependent on this.VPN Pipe Limits and Overhead
Traffic shaping measures the traffic inside VPN tunnels. This is the raw unencrypted data without any protocol overhead so it will be less than the actual VPN traffic. VPN protocols such as IPsec can add significant overhead to the data and for this reason it is recommended that the limits specified in the traffic shaping pipes for VPN traffic are set at around 20% below the actual available bandwidth.However, traffic shaping does take into account the overhead involved in Ethernet and VLANs. Although the 4 CRC32 bytes applied by Ethernet hardware is not included in the traffic calculations.
Limits should not be more than the Available Bandwidth
If pipe limits are set higher than the available bandwidth, the pipe will not know when the physical connection has reached its capacity. If the connection is 500 Kbps but the total pipe limit is set to 600 Kbps, the pipe will believe that it is not full and it will not throttle lower precedences.Limits should be less than Available Bandwidth
Pipe limits should be slightly below the network bandwidth. A recommended value is to make the pipe limit 95% of the physical limit. The need for this difference becomes less with increasing bandwidth since 5% represents an increasingly larger piece of the total.The reason for the lower pipe limit is how cOS Stream processes traffic. For outbound connections where packets leave the Clavister NetShield Firewall, there is always the possibility that cOS Stream might slightly overload the connection because of the software delays involved in deciding to send packets and the packets actually being dispatched from buffers.
For inbound connections, there is less control over what is arriving and what has to be processed by the traffic shaping subsystem and it is therefore more important to set pipe limits slightly below the real connection limit to account for the time needed for cOS Stream to adapt to changing conditions.
Attacks on Bandwidth
Traffic shaping cannot protect against incoming resource exhaustion attacks, such as DoS attacks or other flooding attacks. cOS Stream will prevent these extraneous packets from reaching the hosts behind the Clavister NetShield Firewall, but cannot protect the connection becoming overloaded if an attack floods it.Watching for Leaks
When setting out to protect and shape a network bottleneck, make sure that all traffic passing through that bottleneck passes through the defined pipes.If there is traffic going through the Internet connection that the pipes do not know about, cOS Stream cannot know when the Internet connection becomes full.
The problems resulting from leaks are exactly the same as in the cases described above. Traffic "leaking" through without being measured by pipes will have the same effect as bandwidth consumed by parties outside of administrator control but sharing the same connection.
Troubleshooting
For a better understanding of what is happening in a live setup, the pipe CLI command can be used. For example, to examine the activity of a particular pipe:System:/>
pipe <pipename>
can be used to display a list of currently active users in each pipe.