This chapter shows how to create IPQoS configuration files. Topics that are covered in the chapter include the following.
Defining a QoS Policy in the IPQoS Configuration File (Task Map)
Creating an IPQoS Configuration File for an Application Server
This chapter assumes that you have defined a complete QoS policy, and you 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.
This task map lists the general tasks for creating an IPQoS configuration file.
Task |
Description |
For Instructions |
---|---|---|
1. Plan your IPQoS-enabled network configuration. |
Decide which systems on the local network should become IPQoS enabled. | |
2. Plan the QoS policy for IPQoS systems on your network. |
Identify traffic flows as distinct classes of service. Then, determine which flows require traffic management. | |
3. Create the IPQoS configuration file and define its first action. |
Create the IPQoS file, invoke the IP classifier, and define a class for processing. |
How to Create the IPQoS Configuration File and Define Traffic Classes |
4. Create filters for a class. |
Add the filters that govern which traffic is selected and organized into a class. | |
5. Add more classes and filters to the IPQoS configuration file. |
Create more classes and filters to be processed by the IP classifier. |
How to Create an IPQoS Configuration File for a Best-Effort Web Server |
6. Add an action statement with parameters that configure the metering modules. |
If the QoS policy calls for flow control, assign flow-control rates and conformance levels to the meter. |
How to Configure Flow Control in the IPQoS Configuration File |
7. Add an action statement with parameters that configure the marker. |
If the QoS policy calls for differentiated forwarding behaviors, define how traffic classes are to be forwarded. |
How to Define Traffic Forwarding in the IPQoS Configuration File |
8. Add an action statement with parameters that configure the flow-accounting module. |
If the QoS policy calls for statistics gathering on traffic flows, define how accounting statistics are to be gathered. |
How to Enable Accounting for a Class in the IPQoS Configuration File |
9. Apply the IPQoS configuration file. |
Add the content of a specified IPQoS configuration file into the appropriate kernel modules. |
How to Apply a New Configuration to the IPQoS Kernel Modules |
10. Configure forwarding behaviors in the router files. |
If any IPQoS configuration files on the network define forwarding behaviors, add the resulting DSCPs to the appropriate scheduling files on the router. |
The QoS policy for your network resides in the IPQoS configuration file. You create this configuration file with a text editor. Then, you 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.
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 31–3 and the ipqosconf(1M) man page.
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 27–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
These three configuration files illustrate the most common IPQoS configurations. You might use the sample files that are shown in the next section as templates for your own IPQoS implementation.
This section introduces the IPQoS configuration file by showing how to create a configuration 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 27–4.
The following configuration file defines IPQoS activities for the Goldweb server. This server hosts the web site for Goldco, the company that has purchased a premium SLA.
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. This server hosts web sites for individuals with low-priced, or best-effort, SLAs. This level of service guarantees the best service that can be delivered to best-effort customers after the IPQoS system handles traffic from customers with more expensive SLAs.
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 } }
You can create your first IPQoS configuration file in whatever directory is easiest for you to maintain. 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 28–1.
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 28–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 |
Begins the IPQoS configuration file.
Begins the action statement.
Configures the ipgpc classifier as the first action in the configuration file.
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 the ipqosconf(1M) man page.
Add a params clause with the statistics parameter global_stats.
params { global_stats TRUE } |
The parameter global_stats TRUE in theipgpc.classify statement enables statistics gathering for that action. global_stats TRUE also enables per-class statistics gathering wherever a class clause definition specifies enable_stats TRUE.
Turning on statistics impacts performance. You might want to gather 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(1M) man page.
Define a class that identifies traffic that is bound for the premium server.
class { name goldweb next_action markAF11 enable_stats FALSE } |
This statement is called a class clause. A class clause has the following contents.
Creates the class goldweb to identify traffic that is bound for the Goldweb server.
Instructs the ipgpc module to pass packets of the goldweb class to the markAF11 action statement. The markAF11 action statement calls the dscpmk marker.
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 } |
Creates the class video to identify streaming video traffic that is outgoing from the Goldweb server.
Instructs the ipgpc module to pass packets of the video class to the markEF statement after ipgpc completes processing. The markEF statement calls the dscpmk marker.
Enables statistics collection for the video class. However, because the value of enable_stats is FALSE, statistics collection for this class is not turned on.
To define filters for the class you just created, refer to How to Define Filters in the IPQoS Configuration File.
To create another class clause for the configuration file, refer to How to Create the IPQoS Configuration File and Define Traffic Classes.
The next procedure shows how to define filters for a class in the IPQoS configuration file.
The procedure assumes that you have already started file creation and have defined classes. The steps continue building the /var/ipqos/Goldweb.qos file that is created in How to Create the IPQoS Configuration File and Define Traffic Classes.
As you create the IPQoS configuration file, be very careful to start and end each class clause and each filter clause with curly braces ({ }). For an example of the use of braces, use Example 28–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 } |
Gives the name webout to the filter.
Selects traffic with a source port of 80, the well-known port for HTTP (web) traffic.
Further selects traffic that is outgoing from the local system.
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 } |
Gives the name videoout to the filter.
Selects traffic with a source port of videosrv, a previously defined port for the streaming video application on this system.
Further selects traffic that is outgoing from the local system.
Identifies the class to which the filter belongs, in this instance, class video.
To define forwarding behaviors for the marker modules, refer to How to Define Traffic Forwarding in the IPQoS Configuration File.
To define flow-control parameters for the metering modules, refer to How to Configure Flow Control in the IPQoS Configuration File.
To activate the IPQoS configuration file, refer to How to Apply a New Configuration to the IPQoS Kernel Modules.
To define additional filters, refer to How to Define Filters in the IPQoS Configuration File.
To create classes for traffic flows from applications, refer to How to Configure the IPQoS Configuration File for an Application Server.
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 already defined filters. The steps continue building the /var/ipqos/Goldweb.qos file from Example 28–1.
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 clause 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 |
Calls the marker module dscpmk.
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 } } |
Enables statistics collection for the markAF11 marker action statement. However, because the value of enable_stats is FALSE, statistics are not collected.
Assigns a DSCP of 10 to the packet headers of the traffic class goldweb, which is currently being processed by the marker.
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 DSCP of 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 the DSCP of 10 receive a low-drop, high-priority service. Thus, outgoing traffic for premium customers on Goldweb is given the highest priority that is available for the Assured Forwarding (AF) PHB. For a table of possible DSCPs for AF, refer to Table 31–2.
Start another marker action statement.
action { module dscpmk name markEF |
Calls the marker module dscpmk.
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 } } |
Enables statistics collection on class video, which selects streaming video packets.
Assigns a DSCP of 46 to the packet headers of the traffic class video, which is currently being processed by the marker.
Instructs the dscpmk module to pass packets of the class video to the acct action statement after dscpmk completes processing. The acct action statement invokes the flowacct module.
The DSCP of 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 Expedited Forwarding (EF) per-hop behavior.
The recommended codepoint for EF is 46 (binary 101110). Other DSCPs assign AF PHBs to a packet.
The EF PHB guarantees that packets with the DSCP 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 to streaming applications the EF PHBs in the QoS policy. For more details about the expedited forwarding PHB, refer to Expedited Forwarding (EF) PHB.
Add the DSCPs 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.
To start gathering flow-accounting statistics on traffic flows, refer to How to Enable Accounting for a Class in the IPQoS Configuration File.
To define forwarding behaviors for the marker modules, refer to How to Define Traffic Forwarding in the IPQoS Configuration File.
To define flow-control parameters for the metering modules, refer to How to Configure Flow Control in the IPQoS Configuration File.
To activate the IPQoS configuration file, refer to How to Apply a New Configuration to the IPQoS Kernel Modules.
To define additional filters, refer to How to Define Filters in the IPQoS Configuration File.
To create classes for traffic flows from applications, refer to How to Configure the IPQoS Configuration File for an Application Server.
The next procedure shows how to enable accounting on a traffic class in the IPQoS configuration file. The procedure shows how to define flow accounting for the video class, which is introduced in How to Create 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.
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 28–1.
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 |
Invokes the flow-accounting module flowacct.
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 } } |
Enables statistics collection on the class video, which selects streaming video packets.
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.
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.
Sets the maximum number of active flow records in the flow table for this action instance.
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.
To configure per-hop behaviors on a router, refer to How to Configure a Router on an IPQoS-Enabled Network.
To activate the IPQoS configuration file, refer to How to Apply a New Configuration to the IPQoS Kernel Modules.
To create classes for traffic flows from applications, refer to How to Configure the IPQoS Configuration File for an Application Server.
The IPQoS configuration file for a best-effort web server differs slightly from an IPQoS configuration file for a premium web server. As an example, the procedure uses the configuration file from Example 28–2.
Log in to the best-effort web server.
Create a new IPQoS configuration file with a .qos extension.
fmt_vesion 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 collection. For an explanation of this action statement, see How to Create 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 } |
Creates a class that is called userweb for forwarding web traffic from users.
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.
Enables statistics collection for the userweb class. However, because the value of enable_stats is FALSE, statistics collection for this class does not occur.
For an explanation of the class clause task, see How to Create 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 } } |
Gives the name webout to the filter.
Selects traffic with a source port of 80, the well-known port for HTTP (web) traffic.
Further selects traffic that is outgoing from the local system.
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 |
Invokes the marker module dscpmk.
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 } } |
Enables statistics collection for the markAF12 marker action statement. However, because the value of enable_stats is FALSE, statistics collection does not occur.
Assigns a DSCP of 12 to the packet headers of the traffic class userweb, which is currently being processed by the marker.
Indicates that no further processing is required on packets of the traffic class userweb, and that these packets can return to the network stream.
The DSCP of 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 the DSCP of 12 in the DS field receive a medium-drop, high-priority service.
When you complete the IPQoS configuration file, apply the configuration.
To add classes and other configuration for traffic flows from applications, refer to How to Configure the IPQoS Configuration File for an Application Server.
To configure per-hop behaviors on a router, refer to How to Configure a Router on an IPQoS-Enabled Network.
To activate your IPQoS configuration file, refer to How to Apply a New Configuration to the IPQoS Kernel Modules.
This section explains how to create a configuration file for an application server that provides major applications to customers. The procedure uses as its example the BigAPPS server from Figure 27–4.
The following configuration file defines IPQoS activities for the BigAPPS server. This server hosts FTP, electronic mail (SMTP), and network news (NNTP) for customers.
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_name AF31 green_action_name 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 } }
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 application server. Begin with the following required phrases to start the action statement that invokes the ipgpc classifier:
fmt_version 1.0 action { module ipgpc name ipgpc.classify params { global_stats TRUE } |
For an explanation of the opening action statement, refer to How to Create 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 } |
Creates a class that is called smtp, which includes email traffic flows to be handled by the SMTP application
Enables statistics collection for the smtp class. However, because the value of enable_stats is FALSE, statistics for this class are not taken.
Instructs the ipgpc module to pass packets of the smtp class to the markAF13 action statement after ipgpc completes processing.
Creates a class that is called news, which includes network news traffic flows to be handled by the NNTP application.
Instructs the ipgpc module to pass packets of the news class to the markAF21 action statement after ipgpc completes processing.
Creates a class that is called ftp, which handles outgoing traffic that is handled by the FTP application.
Enables statistics collection for the ftp class.
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 Create the IPQoS Configuration File and Define Traffic Classes.
Define filter clauses to select traffic of the classes defined in Step 2.
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 } } |
Gives the name smtpout to the filter.
Selects traffic with a source port of 25, the well-known port for the sendmail (SMTP) application.
Identifies the class to which the filter belongs, in this instance, class smtp.
Gives the name newsout to the filter.
Selects traffic with a source port name of nntp, the well-known port name for the network news (NNTP) application.
Identifies the class to which the filter belongs, in this instance, class news.
Gives the name ftpout to the filter.
Selects control data with a source port of 21, the well-known port number for FTP traffic.
Gives the name ftpdata to the filter.
Selects traffic with a source port of 20, the well-known port number for FTP data traffic.
Identifies the class to which the ftpout and ftpdata filters belong, in this instance ftp.
To define filters, refer to How to Define Filters in the IPQoS Configuration File.
To define forwarding behaviors for application traffic, refer to How to Configure Forwarding for Application Traffic in the IPQoS Configuration File.
To configure flow control by using the metering modules, refer to How to Configure Flow Control in the IPQoS Configuration File.
To configure flow accounting, refer to How to Enable Accounting for a Class 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 steps continue building the /var/ipqos/BigAPPS.qos file in Example 28–3.
The procedure assumes that you have an existing IPQoS configuration file with already-defined classes and already-defined filters for the applications to be marked.
Open the IPQoS configuration file that you have created for the application server, and 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 } } |
action { module dscpmk name markAF13 |
Invokes the marker module dscpmk.
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 } } |
Enables statistics collection for the markAF13 marker action statement. However, because the value of enable_stats is FALSE, statistics are not collected.
Assigns a DSCP of 14 to the packet headers of the traffic class smtp, which is currently being processed by the marker.
Indicates that no further processing is required on packets of the traffic class smtp. These packets can then return to the network stream.
The DSCP of 14 tells the marker to set all entries in the dscp map to the decimal value 14 (binary 001110). The DSCP of 14 sets the AF13 per-hop behavior. The marker marks packets of the smtp traffic class with the DSCP of 14 in the DS field.
AF13 assigns all packets with a DSCP 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 31–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 } } |
Gives the name markAF21 to the action statement.
Assigns a DSCP of 18 to the packet headers of the traffic class nntp, which is currently being processed by the marker.
The DSCP of 18 tells the marker to set all entries in the dscp map to the decimal value 18 (binary 010010). The DSCP of 18 sets the AF21 per-hop behavior. The marker marks packets of the news traffic class with the DSCP of 18 in the DS field.
AF21 assures that all packets with a DSCP of 18 receive a low-drop precedence, but with only Class 2 priority. Thus, the possibility of network news traffic being dropped is low.
To add configuration information for web servers, refer to How to Create the IPQoS Configuration File and Define Traffic Classes.
To configure flow control by using the metering modules, refer to How to Configure Flow Control in the IPQoS Configuration File.
To configure flow accounting, refer to How to Enable Accounting for a Class in the IPQoS Configuration File.
To configure forwarding behaviors on a router, refer to How to Configure a Router on an IPQoS-Enabled Network.
To activate the IPQoS configuration file, refer to How to Apply a New Configuration to the IPQoS Kernel Modules.
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 meter 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 28–3. In the procedure, you configure not only the meter but also two marker actions that are called within the meter action statement.
The steps assume that you have already defined a class and a filter for the application to be flow-controlled.
Open the IPQoS configuration file that you have created for the applications server.
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 |
Invokes thetokenmt meter.
Gives the name meterftp to the action statement.
Add parameters to configure the meter's rate.
params { committed_rate 50000000 committed_burst 50000000 |
Assigns a transmission rate of 50,000,000 bps to traffic of the ftp class.
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_name markAF22 global_stats TRUE } } |
Indicates that when the traffic flow of the ftp class exceeds the committed rate, packets are sent to the markAF31 marker action statement.
Indicates that when traffic flows of class ftp conform to the committed rate, packets are sent to the markAF22 action statement.
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 } } |
Invokes the marker module dscpmk.
Gives the name markAF31 to the action statement.
Enables statistics for the ftp class.
Assigns a DSCP of 26 to the packet headers of the traffic class ftp whenever this traffic exceeds the committed rate.
Indicates that no further processing is required on packets of the traffic class ftp. Then these packets can return to the network stream.
The DSCP of 26 instructs the marker to set all entries in the dscp map to the decimal value 26 (binary 011010). The DSCP of 26 sets the AF31 per-hop behavior. The marker marks packets of the ftp traffic class with the DSCP of 26 in the DS field.
AF31 assures that all packets with a DSCP of 26 receive a low-drop precedence, but with only Class 3 priority. Therefore, the possibility of nonconformant FTP traffic being dropped is low. For a table of possible AF codepoints, refer to Table 31–2.
Add a marker action statement to assign a per-hop behavior to ftp traffic flows that conform to the committed rate.
action { module dscpmk name markAF22 params { global_stats TRUE dscp_map{0-63:20} next_action continue } } |
Gives the name markAF22 to the marker action.
Assigns a DSCP of 20 to the packet headers of the traffic class ftp whenever ftp traffic conforms to its configured rate.
The DSCP of 20 tells the marker to set all entries in the dscp map to the decimal value 20 (binary 010100). The DSCP of 20 sets the AF22 per-hop behavior. The marker marks packets of the ftp traffic class with the DSCP of 20 in the DS field.
AF22 assures that all packets with a DSCP 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 31–2.
Add the DSCPs that you have created for the application server to the appropriate files on the Diffserv router.
To activate the IPQoS configuration file, refer to How to Apply a New Configuration to the IPQoS Kernel Modules.
To add configuration information for web servers, refer to How to Create the IPQoS Configuration File and Define Traffic Classes.
To configure flow accounting, refer to How to Enable Accounting for a Class in the IPQoS Configuration File.
To configure forwarding behaviors on a router, refer to How to Configure a Router on an IPQoS-Enabled Network.
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 guide.
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 uses as its example the topology in Figure 27–4.
The next procedure assumes that you have already configured the IPQoS systems on your network by performing the previous tasks in this chapter.
Review the configuration files for all IPQoS-enabled systems on your network.
Identify each codepoint that is used in the QoS various policies.
List the codepoints, and the systems and classes, to which the codepoints apply. The next table can illustrate areas where you might have used the same codepoint. This practice is acceptable. However, you should provide other criteria in the IPQoS configuration file, such as a precedence selector, to determine the precedence of identically marked classes.
For example, for the sample network that is used in the procedures throughout this chapter, you might construct the following codepoint table.
System |
Class |
PHB |
DS Codepoint |
---|---|---|---|
Goldweb |
video |
EF |
46 (101110) |
Goldweb |
goldweb |
AF11 |
10 (001010) |
Userweb |
webout |
AF12 |
12 ( 001100) |
BigAPPS |
smtp |
AF13 |
14 ( 001110) |
BigAPPS |
news |
AF18 |
18 ( 010010) |
BigAPPS |
ftp conformant traffic |
AF22 |
20 ( 010100) |
BigAPPS |
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 that you supply should help to configure the router's Diffserv scheduling mechanism. Refer to the router manufacturer's documentation and web sites for instructions.