Amer Networks E5Web GUI - Manual (Page 669)

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: A limit on the lowest precedence has no meaning
Setting a maximum limit for the lowest (best effort) precedence or any lower
precedences has no meaning and will be ignored by cOS Core.
Differentiated Guarantees
A problem arises if the aim is to give a specific 32 Kbps guarantee to Telnet traffic, and a specific
64 Kbps guarantee to SSH traffic. A 32 Kbps limit could be set for precedence 2, a 64 Kbps limit
set for precedence 4 and then pass the different types of traffic through each 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 the traffic shaping scenario becomes more complex.
• The number of precedences is limited. This may not be sufficient in all cases, even without
the "which traffic is more important?" problem.
The solution is to create two new pipes: one for telnet traffic, and one for SSH traffic, much like
the "surf" pipe that was created earlier.
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, it is easy to 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
reserved amount, 64 and 32 Kbps, respectively, of precedence 2 traffic will reach std-in. SSH and
Telnet traffic exceeding their guarantees will reach std-in as precedence 0, the best-effort
precedence of the std-in and ssh-in pipes.
Note: The return chain ordering is important
Here, the ordering of the pipes in the return chain is important. Should std-in appear
Chapter 10: Traffic Management
669