D-Link NetDefend DFL-210 User Manual page 229

10.1.5. Priorities and Guarantees
10.1.5.2. Applying Simple Priorities
Now, how can we use precedences to make some types of traffic more important than others? Let's
continue work on our previous example, by giving SSH and Telnet traffic a higher priority than
everything else passing through our pipes.
For this first example, we do not need to add or change anything in the Pipes section. First, we add a
rule that covers SSH and Telnet traffic:
Copy the pipe settings from the "Standard" rule.
The default precedences of all pipes we have configured so far has been the lowest. To prioritize
traffic above that, we instruct the rule to pass the packet to the pipe chains with a higher precedence.
Let's choose 2.
Now, with this setup, SSH and Telnet traffic is simply prioritized before all other types of traffic.
With these two low-throughput protocols, this behavior is likely not a problem.
However, if this had been real-time audio, it probably would have resulted in the audio streams us-
ing all available bandwidth and leaving none for surfing, DNS, FTP, and all the other protocols.
10.1.5.3. Simple Bandwidth Guarantees
Bandwidth guarantees aren't that much different from prioritizing certain types of traffic. All that
really remains, is to limit the amount of high-priority bandwidth that may be used. The easiest but
least flexible way of doing this is simply limiting how much gets to pass in the higher precedences
of the default pipes.
To change the prioritized SSH and Telnet traffic from the previous example to a 96 kbps guarantee,
you would simply change your std-inpipe to include a 96 kbps limit for precedence 2. Now, does
this mean that your inbound SSH and telnet traffic is limited to 96 kbps? No, it does not.
As previously stated, excess traffic in precedences above the best-effort precedence gets passed to
the best-effort precedence, which, in this example, is the lowest.
Again: Limits in precedences above the best-effort precedence will not actually limit the traffic.
Such limits will only limit how much of the traffic gets to pass in that specific precedence.
So, in this case, the 96 kbps limit in precedence 2 means that you can pass up to 96 kbps worth of
precedence 2 traffic to the std-in pipe, and this traffic will get through, unless there's traffic in even
higher precedences.
If you attempt to pass more than 96 kbps of precedence 2 traffic, the excess traffic will have to com-
pete with all the rest for the remaining bandwidth, and this competition is simple first-come, first-
served, like any Internet connection. Grouping and balancing can improve this situation and these
are discussed later.
10.1.5.4. Differentiated Bandwidth Guarantees
As mentioned earlier, there is a slight problem with the previous way of implementing bandwidth
guarantees: they are not very flexible.
What if, for instance, you want to give a specific 32 kbps guarantee to telnet traffic, and a specific
64 kbps guarantee to SSH traffic? You could set a 32 kbps limit for precedence 2, a 64 kbps limit
for precedence 4, and pass the different types of traffic through each respective precedence.
However, there are two obvious problems with this approach:
• Which traffic is more important? This question does not pose much of a problem here, but it be-
comes more pronounced as your traffic shaping scenario becomes more complex.
• The number of precedences is limited. This may not be sufficient in all cases, even barring the
216
Chapter 10. Traffic Management