| Home Prev |  cOS Stream 4.00.03 Administration Guide
|
Next |
|---|
This section examines how traffic shaping can be used in a variety of scenarios. The configurations discussed are described generally in terms of Pipe objects and traffic filtering criteria. They could be implemented using TrafficProfile objects associated with either IPRule or TrafficShapingRule objects. What is important is to illustrate how Pipe objects are used.
The bandwidth units used throughout are in bits per second but packets per second values could be used instead by setting the corresponding PPS property in Pipe objects. It is possible to also specify both bits per second and packets per second property values for bandwidth limits. When both types of property are specified, the first limit reached is used.
The simplest use of pipes is for bandwidth limiting. This is a scenario that does not require much planning. The example that follows applies a bandwidth limit to inbound traffic only. This is the direction most likely to cause problems for Internet connections.
The examples below show how simple bandwidth can be done in two ways. The first example uses a TrafficShapingRule object, and the second uses an IP Rule object. Both, use a TrafficProfile object and a Pipe object to define the traffic limits.
Example 23.1. Bandwidth Limiting using a Traffic Shaping Rule
This example will use a simple pipe to limit inbound traffic to 2 megabits per second, regardless of what kind of traffic it is.
Command-Line Interface
First, create a Pipe object with the required limit:
System:/> add Pipe std-in-pipe LimitBpsTotal=2M
Next, create a TrafficProfile object that uses this pipe for inbound traffic:
System:/> add TrafficProfile std-prof ReturnChain=std-in-pipe
To create a TrafficShapingRule object that applies the profile to the targeted traffic. Change the CLI context to be the main traffic shaping rule set:
System:/> cc TrafficShapingRulesNow, add the rule:
System:/TrafficShapingRules> add TrafficShapingRule
SourceInterface=if1
SourceNetwork=if1_net
DestinationInterface=wan
DestinationNetwork=all-nets
TrafficProfile=std-prof
Service=all_services
Name=Outbound
Here, we are setting a limit for return traffic for connections that are initiated from the if1_net network out onto the public Internet. No priorities are applied, and neither is any dynamic balancing.
Example 23.2. Bandwidth Limiting using an IP Rule
This example duplicates the previous example but uses an IPRule object to target specific traffic instead of using a TrafficShapingRule object.
Command-Line Interface
First, create a Pipe object with the required limit:
System:/> add Pipe std-in-pipe LimitBpsTotal=2M
Next, create an TrafficProfile object that uses this pipe for inbound traffic:
System:/> add TrafficProfile std-prof ReturnChain=std-in-pipe
Now, create an IPRule object to apply the profile to the targeted traffic. Change the CLI context to be the main rule set:
System:/> cc RuleSet IPRuleSet mainNow, add the rule:
System:/IPRuleSet/main> add IPRule
Acton=Allow
SourceInterface=if1
SourceNetwork=if1_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=all_services
Name=Outbound
TrafficProfile=std-prof Return to the default CLI context:
System:/IPRuleSet/main> ccSystem:/>
Units for Specifying Bandwidth
When specifying bandwidth values there are two considerations:Bits or Packets per Second
Bandwidth can be specified as being either as Bits Per Second or as Packets Per Second. The traffic shaping objects have two corresponding properties for specifying these values. For example, the Pipe object in the above examples used a bits per second total limit that was specified as follows:
System:/> add Pipe std-in-pipe LimitBpsTotal=2MThe limit might have been alternatively specified in terms of some packets per second value:
System:/> add Pipe std-in-pipe LimitPpsTotal=4.2MWhere 4.2M means 4.2 million packets per second.
Units as bps/pps, K, M, G or %
In the above examples, the bandwidth was specified as 2M, where the letter M immediately following the number indicates that the value is in megabits/seconds. The units must be specified when entering bandwidths. The choices are the following:
Note that the units bps or pps can only be used where the property expects that type of value. For example:
System:/> add Pipe std-in-pipe LimitPpsTotal=400pps
Specifying the value as a percentage using the percent sign can only be done where a percentage of a total is being expressed, such as with precedences. A percentage cannot be used with properties that express a total amount, such as with LimitPpsTotal or LimitBpsTotal for a Pipe object.
The number entered before the unit designation does not have to be an integer. It can also be decimal. For example, 2500000bps could be entered as 2500K or 2.5M .
Using a Single Pipe for Both Directions
A single pipe does not care in which direction the traffic through it is flowing when it calculates total throughout. Using the same pipe for both outbound and inbound traffic is allowed but this will not partition the pipe limit exactly in two between the two directions.In the previous example, only bandwidth in the inbound direction is limited. In most situations, this is the direction that becomes full first. But what if the outbound traffic must be limited in the same way?
Just inserting std-in in the forward chain will not work since we probably want the 2 Mbps limit for outbound traffic to be separate from the 2 Mbps limit for inbound traffic. If 2 Mbps of outbound traffic attempts to flow through the pipe in addition to 2 Mbps of inbound traffic, the total attempting to flow is 4 Mbps. Since the pipe limit is 2 Mbps, the actual flow will be close to 1 Mbps in each direction.
Raising the total pipe limit to 4 Mbps will not solve the problem since the single pipe will not know that 2 Mbps of inbound and 2 Mbps of outbound are the intended limits. The result might be 3 Mbps outbound and 1 Mbps inbound since this also adds up to 4 Mbps.
Using Two Separate Pipes for Each Direction
The recommended way to control bandwidth in both directions is to use two separate pipes, one for inbound and one for outbound traffic. In the scenario under discussion, each pipe would have a 2 Mbps limit to achieve the desired result. The following example goes through the setup for this.Example 23.3. Limiting Bandwidth in Both Directions
This example continues on from the previous example and adds a second pipe for outbound traffic which will impose a limit of 2 Mbps.
Command-Line Interface
Create a second pipe for outbound traffic:
System:/> add Pipe std-out LimitBpsTotal=2M
Set the ForwardChain property of the TrafficProfile:
System:/> set TrafficProfile std-prof ForwardChain=std-out
This results in all outbound connections from if1_net being limited to 2 Mbps in each direction.
In the previous examples a static traffic limit for all outbound connections was applied. What if the aim is to limit web surfing more than other traffic? Assume that the total bandwidth limit is 250 Kbps and 125 Kbps of that is to be allocated to inbound web surfing traffic.
The Incorrect Solution
Two "surfing" pipes for inbound and outbound traffic could be set up. However, it is not usually required to limit outbound traffic since most web surfing usually consists of short outbound server requests followed by long inbound responses.Perhaps the solution could be to create a pipe called surf-in with a 125 Kbps limit? A new TrafficProfile could be created to use this as its ReturnChain and the profile could be associated with a new TrafficShapingRule or IPRule object that triggers on the surfing traffic. This new rule would then be placed so it triggers before the rule that directs everything else through the pipe called std-in. That way web surfing traffic goes through the new pipe and everything else is handled by the pipe, profile and rule created earlier.
Unfortunately this will not achieve the desired effect, which is allocating a maximum of 125 Kbps to inbound surfing traffic as part of the 250 Kbps total. Inbound traffic will pass through one of two pipes: one that allows 250 Kbps, and one that allows 125 Kbps, giving a possible total of 375 Kbps of inbound traffic but this exceeds the actual total limit of 250 Kbps.
The Correct Solution
The solution is to create a chain of the pipes surf-in followed by std-in in the TrafficProfile object associated with the TrafficShapingRule or IPRule object that triggers on the surfing traffic.Inbound surfing traffic will now first pass through surf-in and be limited to a maximum of 125 Kbps. Then, it will pass through std-in along with other inbound traffic, which will apply the 250 Kbps total limit.
If web surfing uses the full limit of 125 Kbps, those 125 Kbps will occupy half of the std-in pipe leaving 125 Kbps for the rest of the traffic. If no surfing is taking place then all of the 250 Kbps allowed through std-in will be available for other traffic.
This does not provide a bandwidth guarantee for web browsing but instead limits it to 125 Kbps and provides a 125 Kbps guarantee for everything else. For web browsing the normal rules of first-come, first-forwarded will apply when competing for the 125 Kbps bandwidth. This may mean 125 Kbps, but it may also mean much slower speed if the connection is flooded.
Setting up pipes in this way only puts limits on the maximum values for certain traffic types. It does not give priorities to different types of competing traffic.
