Chapter 3 Creating the IPQoS Configuration File (Tasks)
This chapter shows how to create IPQoS configuration files
and use the ipqosconf utility. Topics that are covered
in the chapter include the following.
The text assumes that you have a complete QoS policy, and are ready
to use this policy as the basis for the IPQoS configuration file. For instructions
on QoS policy planning, refer to Planning the Quality-of-Service Policy.
Defining a QoS Policy in the IPQoS Configuration File (Task Map)
The
next table lists the general tasks for creating an IPQoS configuration file.
Table 3–1 Creating an IPQoS Configuration File (Task Map)
Tools for Creating a QoS Policy
The
QoS policy for your network resides in the IPQoS configuration file. You create
this configuration file with a text editor and provide the file as an argument
to ipqosconf, the IPQoS configuration utility. When you
instruct ipqosconf to apply the policy that is defined
in your configuration file, the policy is written into the kernel IPQoS system.
For detailed information about the ipqosconf command, refer
to the ipqosconf(1m) man page. For instructions on the
use of ipqosconf, refer to How to Apply a New Configuration to the IPQoS Kernel Modules.
IPQoS Configuration File
An
IPQoS configuration file consists of a tree of action statements that implement the QoS policy that you defined in Planning the Quality-of-Service Policy.
The IPQoS configuration file configures the IPQoS modules. Each action statement
contains a set of classes, filters,
or parameters to be processed by the module that is called
in the action statement.
For the complete syntax of the IPQoS configuration file, refer to Example 6–3 and the ipqosconf(1m)
man page.
Configuring the IPQoS Sample Topology
The
tasks in this chapter explain how to create IPQoS configuration files for
three IPQoS-enabled systems. These systems are part of the network topology
of the company BigISP, which was introduced in Figure 2–4.
-
Goldweb – A web server that hosts
web sites for customers who have purchased premium-level SLAs.
-
Userweb – A less-powerful web server
that hosts personal web sites for home users who have purchased “best-effort”
SLAs.
-
BigAPPS – An application server that
serves mail, network news, and FTP to both gold-level and best-effort customers.
The three configuration files illustrate the most common IPQoS configurations.
You might use them as templates for your own IPQoS implementation.
Creating IPQoS Configuration Files for Web Servers
This section introduces IPQoS configuration file
creation by showing how to create a configuration file for a premium web server.
The section then shows how to configure a completely different level of service
in another configuration file for a server that hosts personal web sites.
Both servers are part of the network example that is shown in Figure 2–4.
The following configuration file
defines IPQoS activities for the Goldweb server, which
hosts the web site for Goldco, the company that has purchased a premium SLA.
Example 3–1 Sample IPQoS Configuration File for a Premium Web Server
fmt_version 1.0
action {
module ipgpc
name ipgpc.classify
params {
global_stats TRUE
}
class {
name goldweb
next_action markAF11
enable_stats FALSE
}
class {
name video
next_action markEF
enable_stats FALSE
}
filter {
name webout
sport 80
direction LOCAL_OUT
class goldweb
}
filter {
name videoout
sport videosrv
direction LOCAL_OUT
class video
}
}
action {
module dscpmk
name markAF11
params {
global_stats FALSE
dscp_map{0-63:10}
next_action continue
}
}
action {
module dscpmk
name markEF
params {
global_stats TRUE
dscp_map{0-63:46}
next_action acct
}
}
action {
module flowacct
name acct
params {
enable_stats TRUE
timer 10000
timeout 10000
max_limit 2048
}
}
The following
configuration file defines IPQoS activities on Userweb,
which hosts web sites for individuals with low-priced, or best-effort, SLAs. This SLA level guarantees the best service that can be
delivered to best-effort customers after the IPQoS system handles traffic
from customers with more expensive SLAs.
Example 3–2 Sample Configuration for a Best-Effort Web Server
fmt_version 1.0
action {
module ipgpc
name ipgpc.classify
params {
global_stats TRUE
}
class {
name Userweb
next_action markAF12
enable_stats FALSE
}
filter {
name webout
sport 80
direction LOCAL_OUT
class Userweb
}
}
action {
module dscpmk
name markAF12
params {
global_stats FALSE
dscp_map{0-63:12}
next_action continue
}
}
How to Begin the IPQoS Configuration File and Define Traffic Classes
You can
create your first IPQoS configuration file in whatever directory is easiest
for you to maintain and use. The tasks in this chapter use the directory /var/ipqos as the location for IPQoS configuration files. The next
procedure builds the initial segment of the IPQoS configuration file that
is introduced in Example 3–1.
Note –
As you create the IPQoS configuration file, be very careful to
start and end each action statement and clause with curly braces ({ }). For
an example of the use of braces, see Example 3–1.
-
Log in to the premium web server, and create a new IPQoS configuration
file with a .qos extension.
Every IPQoS configuration file must start with the version number fmt_version 1.0 as its first uncommented line.
-
Follow
the opening parameter with the initial action statement, which configures
the generic IP classifier ipgpc.
This initial action begins the tree of action statements that compose
the IPQoS configuration file. For example, the /var/ipqos/Goldweb.qos file begins with the initial action statement to call the ipgpc classifier.
fmt_version 1.0
action {
module ipgpc
name ipgpc.classify
|
|
Entry
|
Description
|
|
fmt_version 1.0
|
Begins the IPQoS configuration file
|
|
action {
module ipgpc
|
Configures the ipgpc classifier as the first action in the configuration file
|
|
name ipgpc.classify
|
Defines the name of the classifier action statement, which must
always be ipgpc.classify
|
For detailed syntactical information about action
statements, refer to action Statement and theipqosconf(1M) man page.
-
Add a params clause with
the statistics parameter global_stats.
params {
global_stats TRUE
}
|
The parameter global_stats
TRUE in the ipgpc.classify action enables statistics
taking for that action. global_stats TRUE also enables
per-class statistics taking wherever a class clause definition specifies enable_stats TRUE.
Turning on statistics impacts performance. You might want to take statistics
on a new IPQoS configuration file to verify that IPQoS works properly. Later,
you can turn off statistics collection by changing the argument to global_stats to FALSE.
Global statistics are but one type of parameter you can define in a params clause. For syntactical and other details about params clauses, refer to Params Clause and
the ipqosconf man page.
-
Define a class that identifies traffic that is bound for the premium
server.
class {
name goldweb
next_action markAF11
enable_stats FALSE
}
|
The previous statement is called
a class clause. A class clause has the following contents.
|
Entry
|
Description
|
|
name goldweb
|
Creates the class goldweb to identify traffic that is bound
for the Goldweb server.
|
|
next_action markF11
|
Instructs the ipgpc module to pass packets
of the goldweb class to the markAF11
action statement. The markAF11 action statement calls the dscpmk marker.
|
|
enable_stats FALSE
|
Enables statistics taking for the goldweb class. However, because the value of enable_stats is FALSE, statistics for this class are not
turned on.
|
For detailed information about the syntax of
the class clause, see Class Clause and the ipqosconf(1M) man page.
-
Define a class that identifies an application that must have highest-priority
forwarding.
class {
name video
next_action markEF
enable_stats FALSE
}
|
|
Entry
|
Description
|
|
name video
|
Creates the class video
to identify streaming video traffic that is outgoing from Goldweb.
|
|
next_action markEF
|
Instructs the ipgpc module
to pass packets of the video class to the markEF action statement after ipgpc completes processing.
The markEF action statement calls the dscpmk
marker.
|
|
enable_stats FALSE
|
Enables statistics taking for the video class. However, because the value of enable_stats is FALSE, statistics for this class are not
turned on.
|
Where to Go From Here
How to Define Filters in the IPQoS Configuration File
The next procedure shows how to define filters
for a class in the IPQoS configuration file. The procedure assumes that you
have already begun the file and have defined classes. The steps continue building
the /var/ipqos/Goldweb.qos file that is introduced in How to Begin the IPQoS Configuration File and Define Traffic Classes.
Note –
As you create the IPQoS configuration file, be very careful to
start and end each class clause and filter clause with curly braces ({ }).
For an example of the use of braces, use Example 3–1.
-
Open the IPQoS configuration file, and locate the end of the last class
that you defined.
For example, on the IPQoS-enabled server Goldweb
you would start after the following class clause in /var/ipqos/Goldweb.qos.
class {
name video
next_action markEF
enable_stats FALSE
}
|
-
Define a filter clause to
select outgoing traffic from the IPQoS system.
filter {
name webout
sport 80
direction LOCAL_OUT
class goldweb
}
|
|
Entry
|
Description
|
|
name webout
|
Gives the name webout to the filter
|
|
sport 80
|
Selects traffic with a source port of 80, the well-known port for HTTP (Web)
traffic
|
|
direction LOCAL_OUT
|
Further selects traffic that is outgoing from the local system
|
|
class goldweb
|
Identifies the class to which the filter belongs, in this instance, class goldweb
|
For syntactical and detailed information about the filter clause in
the IPQoS configuration file, refer to Filter Clause.
-
Define a filter clause to select streaming video traffic on the IPQoS
system.
filter {
name videoout
sport videosrv
direction LOCAL_OUT
class video
}
|
|
Entry
|
Description
|
|
name videoout
|
Gives the name videoout to the filter
|
|
sport videosrv
|
Selects traffic with a source port of videosrv, a previously
defined port for the streaming video application on this system
|
|
direction LOCAL_OUT
|
Further selects traffic that is outgoing from the local system
|
|
class video
|
Identifies the class to which the filter belongs,
in this instance, class video
|
Where to Go From Here
How to Define Traffic Forwarding in the IPQoS Configuration File
The next procedure shows how to
define traffic forwarding by adding per-hop behaviors for a class into the
IPQoS configuration file. The procedure assumes that you have an existing
IPQoS configuration file with already-defined classes and filters. The steps
continue building the /var/ipqos/Goldweb.qos file from Example 3–1.
Note –
The procedure shows how to configure traffic forwarding by using
the dscpmk marker module. For information about traffic
forwarding on VLAN systems by using the dlclosmk marker,
refer to Using the dlcosmk Marker With VLAN Devices.
-
Open the IPQoS configuration file, and locate the end of the last filter
you defined.
For example, on the IPQoS-enabled server Goldweb, you would start after
the following filter clause in /var/ipqos/Goldweb.qos.
filter {
name videoout
sport videosrv
direction LOCAL_OUT
class video
}
}
|
Note that this filter is at the end of the ipgpc
classifier action statement. Therefore, you need a closing brace to terminate
the filter and a second closing brace to terminate the action statement.
-
Invoke the marker with the following action statement.
action {
module dscpmk
name markAF11
|
|
Entry
|
Description
|
|
module dscpmk
|
Calls the marker module dscpmk
|
|
name markAF11
|
Gives the name markAF11 to the action
statement
|
The previously defined class goldweb includes a next_action markAF11 statement. This statement sends traffic flows
to the markAF11 action statement after the classifier concludes
processing.
-
Define
actions for the marker to take on the traffic flow.
params {
global_stats FALSE
dscp_map{0-63:10}
next_action continue
}
}
|
|
Entry
|
Description
|
|
global_stats FALSE
|
Enables statistics taking for the markAF11
marker action statement. However, because the value of enable_stats is FALSE, statistics are not turned on.
|
|
dscp_map{0–63:10}
|
Assigns a DS codepoint of 10 to the packet
headers of the traffic class goldweb, which is currently
being processed by the marker.
|
|
next_action continue
|
Indicates that no further processing is required
on packets of the traffic class goldweb, and that these packets can return
to the network stream.
|
The DS codepoint 10 instructs the marker
to set all entries in the dscp map to the decimal value
10 (binary 001010). This codepoint indicates that packets of the goldweb traffic class are subject to the AF11 per-hop behavior.
AF11 guarantees that all packets with DS codepoint 10 receive a low-drop,
high-priority service. Thus, outgoing traffic for premium customers on Goldweb
is given the highest priority available for the Assured Forwarding PHB. For
a table of possible DS codepoints for AF, refer to Table 6–2.
-
Start another marker action statement.
action {
module dscpmk
name markEF
|
|
Entry
|
Description
|
|
module dscpmk
|
Calls the marker module dscpmk
|
|
name markEF
|
Gives the name markEF to
the action statement
|
-
Define actions for the marker to take on the traffic flow.
params {
global_stats TRUE
dscp_map{0-63:46}
next_action acct
}
}
|
|
Entry
|
Description
|
|
global_stats TRUE
|
Enables statistics taking on class video, which selects streaming video packets.
|
|
dscp_map{0–63:46}
|
Assigns a DS codepoint of 46
to the packet headers of the traffic class video, which
is currently being processed by the marker.
|
|
next_action acct
|
Instructs the dscpmk module
to pass packets of the video class to the acct action statement after dscpmk completes processing.
The acct action statement invokes the flowacct module.
|
The
DS codepoint 46 instructs the dscpmk module to set all
entries in the dscp map to the decimal value 46 (binary
101110) in the DS field. This codepoint indicates that packets of the video traffic class are subject to the EF per-hop behavior.
Note –
The recommended codepoint for EF is 46 (binary 101110). Other
DS codepoints assign AF PHBs to a packet.
The EF PHB guarantees that packets with the DS codepoint of 46 are given
the highest precedence by IPQoS and diffserv-aware systems. Streaming applications
require highest-priority service, which is the rationale behind assigning
them EF PHBs in the QoS policy. For more details about the expedited forwarding
PHB, refer to Expedited Forwarding (EF) PHB.
-
Add the DS codepoints that you have just created to the appropriate
files on the diffserv router. For more information, refer to How to Configure a Router on an IPQoS-Enabled Network.
Where to Go From Here
How to Enable Accounting for a Class in the IPQoS Configuration File
The
next procedure shows how to enable accounting on a traffic class in the IPQoS
configuration file. The procedure assumes that you have an existing IPQoS
configuration file with already-defined classes, filters, metering actions,
if appropriate, and marking actions, if appropriate. The steps continue building
the /var/ipqos/Goldweb.qos file from Example 3–1.
The procedure shows how to define flow accounting for the video class, which is introduced in How to Begin the IPQoS Configuration File and Define Traffic Classes.
This class selects streaming video traffic, which must be billed as part of
a premium customer's SLA.
-
Open the IPQoS configuration file, and locate the end of the last action
statement you defined.
For example, on the IPQoS-enabled server Goldweb, you would start after
the following markEF action statement in /var/ipqos/Goldweb.qos.
action {
module dscpmk
name markEF
params {
global_stats TRUE
dscp_map{0-63:46}
next_action acct
}
}
|
-
Begin
an action statement that calls flow accounting.
action {
module flowacct
name acct
|
|
Entry
|
Description
|
|
module flowacct
|
Invokes the flow-accounting module flowacct
|
|
name acct
|
Gives the name acct to the action statement
|
-
Define a params clause to
control accounting on the traffic class.
params {
global_stats TRUE
timer 10000
timeout 10000
max_limit 2048
next_action continue
}
}
|
|
Entry
|
Description
|
|
global_stats TRUE
|
Enables statistics taking on class video,
which selects streaming video packets.
|
|
timer 10000
|
Specifies the duration of the interval, in milliseconds, when the flow table
is scanned for timed out flows. In this parameter, that interval is 10000
milliseconds.
|
|
timeout 10000
|
Specifies the minimum interval time-out value. A flow “times out”
when packets for the flow are not seen during a time-out interval. In this
parameter, packets time out after 10000 milliseconds.
|
|
max_limit 2048
|
Sets the maximum number of active flow records in the flow table for this
action instance.
|
|
next_action continue
|
Indicates that no further processing is required
on packets of the traffic class video, and that these packets
can return to the network stream.
|
The flowacct module gathers
statistical information on packet flows of a particular class until a specified timeout value is reached.
Where to Go From Here
How to Create an IPQoS Configuration File for a Best-Effort Web Server
The IPQoS configuration file for a best-effort
web server differs slightly from an IPQoS configuration file for a premium
web server. The following procedure illustrates the similarities and differences
between configuration files for the varying levels of web service. As an example,
the procedure uses the configuration file from Example 3–2.
-
Log in to the best-effort web server.
-
Create a new IPQoS configuration file with a .qos
extension.
fmtversion 1.0
action {
module ipgpc
name ipgpc.classify
params {
global_stats TRUE
}
|
The /var/ipqos/userweb.qos file must begin with
the partial action statement to invoke the ipgpc classifier.
In addition, the action statement also has a params clause to turn on statistics
taking. For an explanation of this action statement, see How to Begin the IPQoS Configuration File and Define Traffic Classes.
-
Define a class that identifies traffic
that is bound for the best-effort web server.
class {
name userweb
next_action markAF12
enable_stats FALSE
}
|
|
Entry
|
Description
|
|
name userweb
|
Creates a class that is called userweb for forwarding web
traffic from users.
|
|
next_action markF12
|
Instructs the ipgpc module to pass packets
of the userweb class to the markAF12
action statement after ipgpc completes processing. The markAF12 action statement invokes the dscpmk
marker.
|
|
enable_stats FALSE
|
Enables statistics taking for the userweb class. However, because the value of enable_stats is FALSE, statistics for this class are not
turned on.
|
For an explanation of the class clause task, see How to Begin the IPQoS Configuration File and Define Traffic Classes.
-
Define a filter clause to select
traffic flows for the userweb class.
filter {
name webout
sport 80
direction LOCAL_OUT
class userweb
}
}
|
|
Entry
|
Description
|
|
name webout
|
Gives the name webout to the filter
|
|
sport 80
|
Selects traffic with a source port of 80, the well-known port for HTTP (Web)
traffic
|
|
direction LOCAL_OUT
|
Further selects traffic that is outgoing from the local system
|
|
class userweb
|
Identifies the class to which the filter belongs, in this instance, class userweb
|
For an explanation of the filter clause task,
see How to Define Filters in the IPQoS Configuration File.
-
Begin the action statement to invoke the dscpmk marker.
action {
module dscpmk
name markAF12
|
|
Entry
|
Description
|
|
module dscpmk
|
Invokes the marker module dscpmk
|
|
name markAF11
|
Gives the name markAF12 to the action
statement
|
The previously defined class userweb includes a next_action markAF12 statement. This statement sends traffic flows
to the markAF12 action statement after the classifier concludes
processing.
-
Define parameters for
the marker to use for processing the traffic flow.
params {
global_stats FALSE
dscp_map{0-63:12}
next_action continue
}
}
|
|
Entry
|
Description
|
|
global_stats FALSE
|
Enables statistics taking for the markAF12
marker action statement. However, because the value of enable_stats is FALSE, statistics are not turned on.
|
|
dscp_map{0–63:12}
|
Assigns a DS codepoint of 12 to the packet
headers of the traffic class userweb, which is currently
being processed by the marker.
|
|
next_action continue
|
Indicates that no further processing is required
on packets of the traffic class goldweb, and that these
packets can return to the network stream.
|
The DS codepoint 12 instructs the marker to set all entries in the dscp map to the decimal value 12 (binary 001100). This codepoint
indicates that packets of the userweb traffic class are
subject to the AF12 per-hop behavior. AF12 guarantees that all packets with
DS codepoint 12 in the DS field receive a medium-drop, high-priority service.
When you complete the IPQoS configuration file, apply the configuration,
as described in How to Apply a New Configuration to the IPQoS Kernel Modules.
Where to Go From Here
Creating an IPQoS Configuration File for an Application Server
This section explains how to create a configuration file for an
applications server that provides a number of major applications to both internal
and external customers. The procedure uses as its example the BigAPPs server
from Figure 2–4.
The following configuration file
defines IPQoS activities for the BigAPPs server, which hosts FTP, electronic
mail (SMTP), and network news (NNTP) for customers.
Example 3–3 Sample Configuration for an Application Server
fmt_version 1.0
action {
module ipgpc
name ipgpc.classify
params {
global_stats TRUE
}
class {
name smtp
enable_stats FALSE
next_action markAF13
}
class {
name news
next_action markAF21
}
class {
name ftp
next_action meterftp
}
filter {
name smtpout
sport smtp
class smtp
}
filter {
name newsout
sport nntp
class news
}
filter {
name ftpout
sport ftp
class ftp
filter {
name ftpdata
sport ftp-data
class ftp
}
}
action {
module dscpmk
name markAF13
params {
global_stats FALSE
dscp_map{0-63:14}
next_action continue
}
}
action {
module dscpmk
name markAF21
params {
global_stats FALSE
dscp_map{0-63:18}
next_action continue
}
}
action {
module tokenmt
name meterftp
params {
committed_rate 50000000
committed_burst 50000000
red_action markAF31
green_action markAF22
global_stats TRUE
}
}
action {
module dscpmk
name markAF31
params {
global_stats TRUE
dscp_map{0-63:26}
next_action continue
}
}
action {
module dscpmk
name markAF22
params {
global_stats TRUE
dscp_map{0-63:20}
next_action continue
}
}
How to Configure the IPQoS Configuration File for an Applications Server
-
Log in to the IPQoS-enabled application server, and create a new IPQoS
configuration file with a .qos extension.
For example, you would create the /var/ipqos/BigAPPS.qos
file for the applications server. Begin with the following required phrases
to start the action statement that invokes the ipgpc classifier.
fmtversion 1.0
action {
module ipgpc
name ipgpc.classify
params {
global_stats TRUE
{
|
For an explanation of the opening action statement, refer to How to Begin the IPQoS Configuration File and Define Traffic Classes.
-
Create classes to select traffic
from three applications on the BigAPPs server.
Add the class definitions after the opening action statement.
class {
name smtp
enable_stats FALSE
next_action markAF13
}
class {
name news
next_action markAF21
}
class {
name ftp
enable_stats TRUE
next_action meterftp
}
|
|
Entry
|
Description
|
|
name smtp
|
Creates a class that is called smtp, which includes email
traffic flows to be handled by the SMTP application.
|
|
enable_stats FALSE
|
Enables statistics taking for the smtp class.
However, because the value of enable_stats is FALSE, statistics for this class are not turned on.
|
|
next_action markAF13
|
Instructs the ipgpc module to pass packets
of the smtp class to the markAF13 action
statement after ipgpc completes processing.
|
|
name news
|
Creates a class that is called news, which includes network
news traffic flows to be handled by the NNTP application.
|
|
next_action markAF21
|
Instructs the ipgpc module to pass packets
of the news class to the markAF21 action
statement after ipgpc completes processing.
|
|
name ftp
|
Creates a class that is called ftp, which handles outgoing
traffic that is handled by the FTP application.
|
|
enable_stats TRUE
|
Enables statistics taking for the ftp class.
|
|
next_action meterftp
|
Instructs the ipgpc module to pass packets
of the ftp class to the meterftp action
statement after ipgpc completes processing.
|
For more information about defining classes, refer to How to Begin the IPQoS Configuration File and Define Traffic Classes.
-
Define filter clauses to select
traffic of the previously defined classes.
filter {
name smtpout
sport smtp
class smtp
}
filter {
name newsout
sport nntp
class news
}
filter {
name ftpout
sport ftp
class ftp
}
filter {
name ftpdata
sport ftp-data
class ftp
}
}
|
|
Entry
|
Description
|
|
name smtpout
|
Gives the name smtpout to the filter
|
|
sport smtp
|
Selects traffic with a source port of 25, the well-known port for the sendmail (SMTP) application
|
|
class smtp
|
Identifies the class to which the filter belongs, in this instance, class smtp
|
|
name newsout
|
Gives the name newsout to the filter
|
|
sport nntp
|
Selects traffic with a source port name of nntp, the well-known
port name for the network news application
|
|
class news
|
Identifies the class to which the filter belongs, in this instance, class news
|
|
name ftpout
|
Gives the name ftpout to the filter
|
|
sport ftp
|
Selects control data with a source port of 21, the well-known port number
for FTP traffic
|
|
name ftpdata
|
Gives the name ftpdata
to the filter
|
|
sport ftp-data
|
Selects traffic with a source port of 20,
the well-known port number for FTP data traffic
|
|
class ftp
|
Identifies the class to which the ftpout and ftpdata filters belong, in this instance ftp
|
For more information about defining filters, refer to How to Define Filters in the IPQoS Configuration File.
Where to Go From Here
How to Configure Forwarding for Application Traffic in the IPQoS Configuration
File
The next procedure shows how to
configure forwarding for application traffic. In the procedure, you define
per-hop behaviors for application traffic classes that might have lower precedence
than other traffic on a network. The procedure assumes that you have an existing
IPQoS configuration file with already-defined classes and filters for the
applications to be marked. The steps continue building the /var/ipqos/BigAPPs.qos file in Example 3–3.
-
Open the IPQoS configuration file you have created for the applications
server.
Locate the end of the last filter clause. In the /var/ipqos/BigAPPs.qos file, the last filter is the following:
filter {
name ftpdata
sport ftp-data
class ftp
}
}
|
-
Invoke the marker as follows:
action {
module dscpmk
name markAF13
|
|
Entry
|
Description
|
|
module dscpmk
|
Invokes the marker module dscpmk
|
|
name markAF13
|
Gives the name markAF13 to the action
statement
|
-
Define the per-hop behavior to be marked on electronic mail traffic
flows.
params {
global_stats FALSE
dscp_map{0-63:14}
next_action continue
}
}
|
|
Entry
|
Description
|
|
global_stats FALSE
|
Enables statistics taking for the markAF13
marker action statement. However, because the value of enable_stats is FALSE, statistics are not turned on.
|
|
dscp_map{0–63:14}
|
Assigns a DS codepoint of 14 to the packet
headers of the traffic class smtp, which is currently being
processed by the marker.
|
|
next_action continue
|
Indicates that no further processing is required
on packets of the traffic class smtp. These packets can
then return to the network stream.
|
The DS codepoint 14 tells the marker to set all entries in the dscp map to the decimal value 14 (binary 001110). This value sets
the AF13 per-hop behavior and marks packets of the smtp
traffic class with the DS codepoint 14 in the DS field.
AF13 assigns all packets with a DS codepoint of 14 to a high-drop precedence.
However, because AF13 also assures a Class 1 priority, the router still guarantees
outgoing email traffic a high priority in its queue. For a table of possible
AF codepoints, refer to Table 6–2.
-
Add a marker action statement to define a per-hop behavior for network
news traffic:
action {
module dscpmk
name markAF21
params {
global_stats FALSE
dscp_map{0-63:18}
next_action continue
}
}
|
The next table explains parameters that have not yet been defined in
this procedure.
|
Entry
|
Description
|
|
name markAF21
|
Gives the name markAF21 to the action
statement
|
|
dscp_map{0–63:18}
|
Assigns a DS codepoint of 18 to the packet
headers of the traffic class nntp, which is currently being
processed by the marker
|
The DS codepoint 18 tells the marker to set all entries in the dscp map to the decimal value 18 (binary 010010). This value sets
the AF21 per-hop behavior and marks packets of the news
traffic class with the DS codepoint 18 in the DS field.
AF21 assures that all packets with a DS codepoint of 18 receive a low-drop
precedence, but with only Class 2 priority. Thus, the possibility of network
news traffic being dropped is low, but the router gives a higher forwarding
probability to traffic classes with a Class 1 mark.
Where to Go From Here
How to Configure Flow Control in the IPQoS Configuration File
To control the rate at which
a particular traffic flow is released onto the network, you must define parameters
for the meter. You can use either of the two metering modules, tokenmt or tswtclmt, in the IPQoS configuration
file.
The next procedure continues to build the IPQoS configuration file for
the application server in Example 3–3. In
the procedure, you configure not only the meter but also
two marker actions that are called within the meter action statement.
-
Open the IPQoS configuration file you have created for the applications
server.
The remaining steps assume that you have already defined a class and
a filter for the application to be flow-controlled. In the /var/ipqos/BigAPPs.qos file, you begin after the following marker action:
action {
module dscpmk
name markAF21
params {
global_stats FALSE
dscp_map{0-63:18}
next_action continue
}
}
|
-
Create
a meter action statement to flow-control traffic of the ftp
class:
action {
module tokenmt
name meterftp
|
|
Entry
|
Definition
|
|
module tokenmt
|
Invokes the tokenmt meter
|
|
name meterftp
|
Gives the name meterftp to the action statement
|
-
Add parameters to configure the meter's rate:
params {
committed_rate 50000000
committed_burst 50000000
|
|
Entry
|
Description
|
|
committed_rate 50000000
|
Assigns a transmission rate of 5,000,0000 bits-per-second to
traffic of the ftp class
|
|
committed_burst 50000000
|
Commits a burst size of 50,000,000 bits to traffic of the ftp class
|
For an explanation of tokenmt parameters, refer to Configuring tokenmt as a Two-Rate Meter.
-
Add parameters to configure traffic conformance
precedences:
red_action markAF31
green_action markAF22
global_stats TRUE
}
}
|
|
Entry
|
Description
|
|
red_action markAF31
|
Indicates that when the traffic flow of the ftp
class becomes nonconformant, that is, exceeds the committed rate, packets
are sent to the markAF31 marker action statement
|
|
green_action markAF22
|
Indicates that when traffic flows of class ftp
conform to the committed rate, packets are sent to the markAF22
action statement
|
|
global_stats TRUE
|
Enables metering statistics for the ftp class
|
For more information about traffic conformance, see Meter Module.
-
Add a marker action statement
to assign a per-hop behavior to nonconformant traffic flows of class ftp.
action {
module dscpmk
name markAF31
params {
global_stats TRUE
dscp_map{0-63:26}
next_action continue
}
}
|
|
Entry
|
Description
|
|
module dscpmk
|
Invokes the marker module dscpmk.
|
|
name markAF31
|
Gives the name markAF31 to the action statement.
|
|
global_stats TRUE
|
Enables statistics for the ftp
class.
|
|
dscp_map{0–63:26}
|
Assigns a DS codepoint of 26
to the packet headers of the traffic class ftp whenever
this traffic exceeds the committed rate.
|
|
next_action continue
|
Indicates that no further processing is required
on packets of the traffic class ftp. Then these packets
can return to the network stream.
|
The DS codepoint 26 instructs the marker to set all entries in the dscp map to the decimal value 26 (binary 011010). This value sets
the AF31 per-hop behavior and marks packets of the ftp
traffic class with the DS codepoint 26 in the DS field.
AF31 assures that all packets with a DS codepoint of 26 receive a low-drop
precedence, but with only Class 3 priority. Therefore, the possibility of
nonconformant FTP traffic being dropped is low. However, the router gives
a higher forwarding probability to traffic classes with a Class 1 or Class
2 low-drop precedence mark or better. For a table of possible AF codepoints,
refer to Table 6–2.
-
Add a marker action
statement to assign a per-hop behavior to traffic flows of class ftp that conform to the committed rate.
action {
module dscpmk
name markAF22
params {
global_stats TRUE
dscp_map{0-63:20}
next_action continue
}
}
|
The next table contains parameters that are not defined in the previous
step.
|
Entry
|
Description
|
|
name markAF22
|
Gives the name markAF22 to the marker action
|
|
dscp_map{0–63:20}
|
Assigns a DS codepoint of 20
to the packet headers of the traffic class ftp whenever ftp traffic conforms to its configured rate
|
The DS codepoint 20 tells the marker to set all entries in the dscp map to the decimal value 20 (binary 010100). This value sets
the AF22 per-hop behavior and marks packets of the ftp
traffic class with the DS codepoint 20 in the DS field.
AF22 assures that all packets with a DS codepoint of 20 receive a medium-drop
precedence with Class 2 priority. Therefore, conformant FTP traffic is assured
a medium-drop precedence among flows that are simultaneously released by the
IPQoS system. However, the router gives a higher forwarding priority to traffic
classes with a Class 1 medium-drop precedence mark or higher. For a table
of possible AF codepoints, refer to Table 6–2.
-
Add the DS codepoints that you have created for the application server
to the appropriate files on the diffserv router. For more information, refer
to How to Configure a Router on an IPQoS-Enabled Network.
Where to Go From Here
Providing Differentiated Services on a Router
To provide true differentiated services, you must
include a diffserv-aware router in your network topology, as described in Hardware Strategies for the Diffserv Network. The actual steps for configuring diffserv
on a router and updating that router's files are outside the scope of this
document.
This section gives general steps for coordinating the forwarding information
among various IPQoS-enabled systems on the network and the diffserv router.
The next procedure assumes that you have already configured the IPQoS systems
on your network by performing the previous tasks in this chapter.
How to Configure a Router on an IPQoS-Enabled Network
The next procedure uses as its
example the topology in Figure 2–4.
-
Review the configuration files for all IPQoS-enabled systems on your
network.
-
Identify each codepoint that is used in the various policies.
List the codepoints, and the systems
and classes, to which the codepoints apply. The table can illustrate areas
where you might have used the same codepoint. This practice is acceptable,
but you should provide other criteria in the IPQoS configuration file, such
as a precedence selector, to be used to determine the precedence
of identically marked classes.
For example, for the sample network that is used in the procedures of
this chapter, you might construct the following codepoint table.
Table 3–2 Per-Hop Behaviors Configured for a Sample Network
|
System
|
Class
|
PHB
|
DS Codepoint
|
|
Goldweb
|
video
|
EF
|
46 (101110)
|
|
“ “
|
goldweb
|
AF11
|
10 (001010)
|
|
Userweb
|
webout
|
AF12
|
12 ( 001100)
|
|
BigAPPs
|
smtp
|
AF13
|
14 ( 001110)
|
|
“
|
news
|
AF18
|
18 ( 010010)
|
|
“
|
ftp conformant traffic
|
AF22
|
20 ( 010100)
|
|
“
|
ftp nonconformant traffic
|
AF31
|
26 ( 011010)
|
-
Add the codepoints from your network's IPQoS configuration files to
the appropriate files on the diffserv router.
The codepoints you supply should help to configure the router's diffserv
scheduling mechanism. Refer to the router manufacturers' documentation and
web sites for instructions.
Загрузить это руководство в формате PDF (656 КБ)