D-Link 800 - DFL 800 - Security Appliance, User Manual

Page: 386 / 469

Bandwidth guarantees ensure that there is a minimum amount of bandwidth available for a given
precedence. This is done by specifying a maximum limit for the precedence in a pipe. This will be
the maximum amount of bandwidth that the precedence will accept and will send ahead of lower
precedences. Excess traffic above this limit will be sent at the Best Effort precedence, behind traffic
at precedences higher than Best Effort.
To change the prioritized SSH and Telnet traffic from the previous example to a 96 kbps guarantee,
you set the precedence 2 limit for the std-inpipe to be 96 kbps.
This does not mean that inbound SSH and Telnet traffic is limited to 96 kbps. Limits in precedences
above the Best Effort precedence will only limit how much of the traffic gets to pass in that specific
precedence.
If more than 96 kbps of precedence 2 traffic arrives, any excess traffic will be moved down to the
Best Effort precedence. All traffic at the Best Effort precedence is then forwarded on a first-come,
first-forwarded basis.
Note
Setting a maximum limit for the lowest (Best Effort) precedence or any lower
precedences has no meaning and will be ignored by NetDefendOS.
10.1.8. Differentiated Guarantees
A problem arises if 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
becomes 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
"which traffic is more important?" problem.
The solution here is to create two new pipes: one for telnet traffic, and one for SSH traffic, much
like the "surf" pipe that we created earlier on.
First, remove the 96 kbps limit from the std-in pipe, then create two new pipes: ssh-in and
telnet-in. Set the default precedence for both pipes to 2, and the precedence 2 limits to 32 and 64
kbps, respectively.
Then, split the previously defined rule covering ports 22 through 23 into two rules, covering 22 and
23, respectively:
Keep the forward chain of both rules as std-out only. Again, to simplify this example, we
concentrate only on inbound traffic, which is the direction that is the most likely to be the first one
to fill up in client-oriented setups.
Set the return chain of the port 22 rule to ssh-in followed by std-in.
Set the return chain of the port 23 rule to telnet-in followed by std-in.
Set the priority assignment for both rules to Use defaults from first pipe; the default precedence of
both the ssh-in and telnet-in pipes is 2.
Using this approach rather than hard-coding precedence 2 in the rule set, you can easily change the
precedence of all SSH and Telnet traffic by changing the default precedence of the ssh-in and
telnet-in pipes.
Notice that we did not set a total limit for the ssh-in and telnet-in pipes. We do not need to since the
total limit will be enforced by the std-in pipe at the end of the respective chains.
The ssh-in and telnet-in pipes act as a "priority filter": they make sure that no more than the
10.1.8. Differentiated Guarantees Chapter 10. Traffic Management
386