[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

System Management Guide: Communications and Networks

TCP/IP Quality of Service (QoS)

Quality of Service (QoS) is a family of evolving Internet standards that provides ways to give preferential treatment to certain types of IP traffic. With the proper support for QoS along a route, this can ameliorate the effects of variable queueing delays and congestion that contribute to poor network performance. The operating system provides host support for QoS to classify outbound traffic into distinct classes of service and to announce and establish resource reservations as requested by client applications.

QoS can be used by an institution to deploy and enforce network policies governing the use of network bandwidth. With QoS, a host can:

The QoS support provides the following functions:

The QoS subsystem consists of four components:

QoS kernel extension (/usr/lib/drivers/qos)
The QoS kernel extension resides in /usr/lib/drivers/qos and is loaded and unloaded using the cfgqos and ucfgqos configuration methods. This kernel extension enables QoS support.
Policy agent (/usr/sbin/policyd)
The policy agent is a user-level daemon that resides in /usr/sbin/policyd. It provides support for policy management and interfaces with the QoS kernel extension to install, modify, and delete policy rules. Policy rules can be defined in the local configuration file (/etc/policyd.conf), retrieved from a central network policy server using LDAP, or both.
RSVP agent (/usr/sbin/rsvpd)
The RSVP agent is a user-level daemon that resides in /usr/sbin/rsvpd. It implements the RSVP signaling protocol semantics.
RAPI shared library (/usr/lib/librapi.a)
Applications can use the RSVP API (RAPI) to request enhanced quality of service as defined by the Integrated Services Internet QoS model. This library interacts with the local RSVP agent to propagate the QoS request along the path of the data flow using the RSVP protocol. This API is an open standard.

Note: This implementation of QoS is based on a set of evolving Internet standards and draft standards currently under development by the Internet Engineering Task Force (IETF) and its various working groups. This technology will become more consistent and well defined as these standardization efforts progress within the IETF. It is also important to note that QoS is an emerging Internet technology that is just beginning to be deployed within the Internet. There are many benefits of QoS at all stages of deployment. However, true end-to-end services can only be realized when QoS support exists all along a particular route.

QoS Models

The QoS models for the Internet are open standards defined by the IETF. There are two Internet QoS models currently being standardized within the IETF: integrated services and differentiated services. These two Internet QoS models augment the traditional best-effort service model described in RFC 1812.

Integrated Services

Integrated Services (IS) is a dynamic resource reservation model for the Internet described in RFC 1633. Hosts use a signaling protocol called Resource ReSerVation Protocol (RSVP) to dynamically request a specific quality of service from the network. QoS parameters are carried in these RSVP messages and each network node along the path installs the parameters to obtain the requested quality of service. These QoS parameters describe one of two currently defined services, guaranteed service and controlled-load service. An important characteristic of IS is that this signaling is done for each traffic flow and reservations are installed at each hop along the route. Although this model is well-suited for meeting the dynamically changing needs of applications, there exist some significant scaling issues that imply it cannot be deployed in a network in which single routers handle many simultaneous flows.

Differentiated Services

Differentiated Services (DS) removes the per-flow and per-hop scalability issues, replacing them with a simplified mechanism of classifying packets. Rather than a dynamic signaling approach, DS uses bits in the IP type of service (TOS) byte to separate packets into classes. The particular bit pattern in the IP TOS byte is called the DS codepoint and is used by routers to define the quality of service delivered at that particular hop, in much the same way routers do IP forwarding using routing table lookups. The treatment given to a packet with a particular DS codepoint is called a per-hop behavior (PHB) and is administered independently at each network node. When the effects of these individual, independent PHBs are concatenated, this results in an end-to-end service.

Differentiated services is being standardized by an IETF working group, which has defined three PHBs: the Expedited Forwarding (EF) PHB, the Assured Forwarding (AF) PHB group, and the Default (DE) PHB. The EF PHB can be used to implement a low latency, low jitter, low loss, end-to-end service such as a virtual leased line (VLL). AF is a family of PHBs, called a PHB group, that is used to classify packets into various drop precedence levels. The drop precedence assigned to a packet determines the relative importance of a packet within the AF class. It can be used to implement the so-called Olympic service, which consists of three classes: bronze, silver, and gold. The DE PHB is the traditional best-effort service model as standardized in RFC 1812.

Supported Standards and Draft Standards

The following RFCs and Internet drafts describe the standards on which this QoS implementation is based.

RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 2475 An Architecture for Differentiated Services
RFC 1633 Integrated Services in the Internet Architecture: an Overview
RFC 2205 Resource ReSerVation Protocol (RSVP)
RFC 2210 The Use of RSVP with IETF Integrated Services
RFC 2211 Specification of the Controlled-Load Network Element Service
RFC 2212 Specification of Guaranteed Quality of Service
RFC 2215 General Characterization Parameters for Integrated Service Network Elements
draft-ietf-diffserv-framework-01.txt,
October 1998
A Framework for Differentiated Services
draft-ietf-diffserv-rsvp-01.txt,
November 1998
A Framework for Use of RSVP with DIFF-serv Networks
draft-ietf-diffserv-phb-ef-01.txt An Expedited Forwarding PHB
draft-ietf-diffserv-af-04.txt Assured Forwarding PHB Group
draft-rajan-policy-qosschema-00.txt,
October 1998
Schema for Differentiated Services and Integrated Services in Networks
draft-ietf-rap-framework-01.txt,
November 1998
A Framework for Policy-based Admission Control[25]
draft-ietf-rap-rsvp-ext-01.txt,
November 1998
RSVP Extensions for Policy Control

Note: QoS is an emerging Internet technology that is just beginning to be deployed within the Internet. There are many benefits of QoS at all stages of deployment. However, true end-to-end services can only be realized when QoS support exists all along a particular route.

QoS Installation

QoS is packaged with bos.net.tcp.server. This fileset must be installed in order to use QoS. To use the RAPI shared library, bos.adt.include must also be installed.

QoS Configuration

Stopping and Starting the QoS Subsystem

QoS can be started or stopped through SMIT with the smit qos fast path or with the mkqos and rmqos commands.

To disable the QoS subsystem now and on the next system restart:

    /usr/sbin/rmqos -B

To enable the QoS subsystem now only:

    /usr/sbin/mkqos -N

See the command descriptions for mkqos and rmqos for the startup and removal command flags.

The policyd and rsvpd daemons are configured through the /etc/policyd.conf and /etc/rsvpd.conf configuration files, respectively. These configuration files must be edited to customize the QoS subsystem to the local environment. QoS does not work correctly with the supplied example configurations.

Configuring the RSVP agent

The RSVP agent is required if the host is to support the RSVP protocol. The /etc/rsvpd.conf configuration file is used to configure the RSVP agent. The syntax of the configuration file is described in the sample configuration file installed in /etc/rsvpd.conf.

Example Configuration

    interface 1.2.3.1
    interface 1.2.3.2 disabled
    interface 1.2.3.3 disabled
    interface 1.2.3.4
    {
      trafficControl
    }

    rsvp 1.2.3.1
    {
      maxFlows 64
    }

    rsvp 1.2.3.4
    {
      maxFlows 100
    }

The example illustrates a possible RSVP configuration in which the host has 4 interfaces (virtual or physical) given by the 4 IP addresses, 1.2.3.1, 1.2.3.2, 1.2.3.3, and 1.2.3.4.

Interface 1.2.3.1 has been enabled for RSVP. However, traffic control has not been specified and incoming RSVP RESV messages do not cause resource reservation within the TCP subsystem. This interface can support a maximum of 64 simultaneous RSVP sessions.

Interfaces 1.2.3.2 and 1.2.3.3 have been disabled. The RSVP agent cannot use this interface to transmit or receive RSVP messages.

Interface 1.2.3.4 has been enabled for RSVP. In addition, it can install resource reservations into the TCP subsystem in response to an RSVP RESV message. This interface can support up to 100 RSVP sessions.

Any other interfaces present on the host but not mentioned explictly in /etc/rsvpd.conf are disabled.

Configuring the Policy Agent

The policy agent is a required component of the QoS subsystem. The /etc/policyd.conf configuration file is used to configure the policy agent. The syntax of this configuration file is described in the sample configuration file installed in /etc/policyd.conf.

The policy agent can be configured by editing /etc/policyd.conf. Additionally, the following commands are provided to assist in configuring policies:

Example Configurations

In the following example, a premium service category is created and used in the tcptraffic policy rule. This service category has a maximum rate of 110000 Kbps, a token bucket depth of 10000 bits, and an outgoing IP TOS value of 11100000 in binary. The tcptraffic policy rule gives this premimum service to all traffic with source IP address given by 1.2.3.6, destination address 1.2.3.3, and destination port in the range 0 to 1024.

    ServiceCategories  premium
    {
       PolicyScope     DataTraffic
       MaxRate         110000
       MaxTokenBucket  10000
       OutgoingTOS     11100000
    }

    ServicePolicyRules   tcptraffic
    {
       PolicyScope    DataTraffic
       ProtocolNumber 6  # tcp
       SourceAddressRange      1.2.3.6-1.2.3.6
       DestinationAddressRange 1.2.3.3-1.2.3.3
       DestinationPortRange    0-1024
       ServiceReference        premium
    }

The following statements set up a default service category and use it to restrict the UDP traffic flowing from interfaces 1.2.3.1 through 1.2.3.4 to IP addresses 1.2.3.6 through 1.2.3.10, port 8000.

    ServiceCategories  default
    {
       MaxRate         110000
       MaxTokenBucket  10000
       OutgoingTOS     00000000
    }

    ServicePolicyRules   udptraffic
    {
       ProtocolNumber 17  # udp
       SourceAddressRange      1.2.3.1-1.2.3.4
       DestinationAddressRange 1.2.3.6-1.2.3.10
       DestinationPortRange    8000-8000
       ServiceReference        default
    }

The followoing example configuration can be used to download rules from an LDAP server using the distinguished subtree name, to lookup the policies on the LDAP server host.

    ReadFromDirectory
    {
      LDAP_Server      1.2.3.27
      Base             ou=NetworkPolicies,o=myhost.mydomain.com,c=us
    }

QoS Problem Determination

The qosstat command may be used to display status information about the installed and active policies in the QoS subsystem. This information may be useful to you in determining where a problem exists if you are troubleshooting your QoS configuration. qosstat can be used to generate the following report.

Action:
  Token bucket rate (B/sec): 10240
  Token bucket depth (B): 1024
  Peak rate (B/sec): 10240
  Min policied unit (B): 20
  Max packet size (B): 1452
  Type: IS-CL
  Flags: 0x00001001 (POLICE,SHAPE)

  Statistics:
    Compliant packets: 1423 (440538 bytes)

  Conditions:
    Source address        Dest address          Protocol
    192.168.127.39:8000   192.168.256.29:35049  tcp       (1 connection)

Action:
  Token bucket rate (B/sec): 10240
  Token bucket depth (B): 1024
  Peak rate (B/sec): 10240
  Outgoing TOS (compliant): 0xc0
  Outgoing TOS (non-compliant): 0x00
  Flags: 0x00001011 (POLICE,MARK)
  Type: DS

  Statistics:
    Compliant packets: 335172 (20721355 bytes)
    Non-compliant packets: 5629 (187719 bytes)

  Conditions:
    Source address        Dest address          Protocol
    192.168.127.39:80     *:*                   tcp       (1 connection)
    192.168.127.40:80     *:*                   tcp       (5 connections)

Policy Specification

This section describes the object classes and attributes used by the policy agent to specify policies for quality of service (QoS) on outgoing traffic. The object classes and attributes are defined, followed by guidelines to enable marking, policing, and shaping.

These conventions are used in the explanations that follow

.

      p  : choose one in the allowed parameter set
      B  : integer value of a byte (i.e., 0 =< B =< 255)
      b  : bit string starting with left most bit (e.g., 101 is
           equivalent 10100000 in a byte field)
      i  : integer value
      s  : a character string
      a  : IP address format B.B.B.B
     (R) : Required parameter
     (O) : Optional parameter

ReadFromDirectory

This statement specifies parameters for establishing an LDAP session. The ReadFromDirectory statement is used in the /etc/policyd.conf file to establish the LDAP session.

         ReadFromDirectory
         {
           LDAP_Server    a   # IP address of directory server running LDAP
           LDAP_Port     i    # Port number LDAP server is listening to
           Base     s         # Distinguished Name for LDAP usage
           LDAP_SelectedTag s # Tag to match SelectorTag in object classes
         }

where

      LDAP_Server (R): IP address of LDAP server
      LDAP_Port   (0): Unique port number, default port is 389
      Base        (R): Example is o=ibm, c=us where o is your organization and c is country
      LDAP_SelectedTag (R): Unique string matching SelectorTag attribute in the object class

ServiceCategories

This statement specifies the type of service that a flow of IP packets (for example, from a TCP connection or UDP data) should receive end-to-end as they traverse the network. ServiceCategories can be repeated with each having a different name so that they can be referred to later. A ServiceCategories object requires ServicePolicyRules to complete the policy definition.

         ServiceCategories   s
         {
            SelectorTag    s     # Required tag for LDAP Search
            MaxRate        i     # Target rate for traffic in this service class
            MaxTokenBucket i     # The bucket depth
            OutgoingTOS    b     # TOS value of outbound traffic for this service class
            FlowServiceType   p  # Type of traffic

         }

where

         s           (R)     : is the name of this service category
         SelectorTag (R)     : Required only for LDAP to Search object classes
         MaxRate     (O)     : in Kbps (K bits per second), default is 0
         MaxTokenBucket(O)   : in Kb, default is system defined maximum
         OutgoingTOS (O)     : default is 0
         FlowServiceType  (O): ControlledLoad | Guaranteed, default is ControlledLoad

ServicePolicyRules

This statement specifies characteristics of IP packets that are used to match to a corresponding service category. In other words, it defines a set of IP datagrams that should receive a particular service. ServicePolicyRules are associated with ServiceCategories through the ServiceReference attribute. If two rules refer to the same ServiceCategory, each rule is associated with a unique instance of the ServiceCategory.

         ServicePolicyRules   s
         {
            SelectorTag       s   # Required tag for LDAP Search
            ProtocolNumber    i   # Transport protocol id for the policy rule
            SourceAddressRange      a1-a2
            DestinationAddressRange a1-a2
            SourcePortRange         i1-i2
            DestinationPortRange    i1-i2
            PolicyRulePriority  i       # Highest value is enforced first
            ServiceReference        s  # Service category name which for this policy rule
         }

where

         s           (R): is the name of this policy rule
         SelectorTag (R): required only for LDAP to Search object class
         ProtocolNumber     (R): default is 0 which causes no match, must explicity specify
         SourceAddressRange (O): from a1 to a2 where a2 >= a1, default is 0, any source address
         SourcePortRange    (O): from i1 to i2 where i2 >= i1, default is 0, any source port
         DestinationAddressRange (O): same as SourceAddressRange
         DestinationPortRange    (O): same as SourcePortRange
         PolicyRulePriority	(O): Important to specify when ovelapping policies exist
         ServiceReference   (R): service category this rule uses

Guidelines for DiffServ Environments

The following are guidelines to specify policies for marking, shaping, and/or policing in a DiffServ environment.

  1. Marking Only

        OutgoingTOS     : Desired Type Of Service
        FlowServiceType : ControlledLoad
        MaxRate         : Take default of 0
  2. Shaping Only

        OutgoingTOS     : Take default of 0
        FlowServiceType : Guaranteed
        MaxRate         : Target rate desired for traffic as a positive integer
  3. Marking and Policing (See Note)

        OutgoingTOS     : Desired Type of Service
        FlowServiceType : ControlledLoad
        MaxRate         : Target rate desired for traffic as a positive integer
  4. Marking and Shaping

        OutgoingTOS     : Desired Type of Service
        FlowServiceType : Guaranteed
        MaxRate         : Target rate desired for traffic as a positive integer

Note: The type of service set for the out of profile packets is set to zero in the case of policing.

Sample policyd Configuration File

The following is a complete example of the /etc/policyd.conf configuration file.

policyd Configuration File

#loglevel  511    # Verbose logging

######################################################################
#
# Mark rsh traffic on TCP source ports 513 and 514.
ServiceCategories       tcp_513_514_svc
{
        MaxRate                 0               # Mark only
        OutgoingTOS             00011100        # binary
        FlowServiceType         ControlledLoad
}

ServicePolicyRules      tcp_513_514_flt
{
        ProtocolNumber          6  # TCP
        SourceAddressRange      0.0.0.0-0.0.0.0 # Any IP src addr
        DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
        SourcePortRange         513-514
        DestinationPortRange    0-0             # Any dst port
        ServiceReference        tcp_513_514_svc
}
#
######################################################################
#
# Shape connected UDP traffic on source port 9000.
ServiceCategories       udp_9000_svc
{
        MaxRate                 8192     # kilobits
        MaxTokenBucket          64       # kilobits
        FlowServiceType         Guaranteed
}

ServicePolicyRules      udp_9000_flt
{
        ProtocolNumber          17  # UDP
        SourceAddressRange      0.0.0.0-0.0.0.0 # Any IP src addr
        DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
        SourcePortRange         9000-9000
        DestinationPortRange    0-0             # Any dst port
        ServiceReference        udp_9000_svc
}
#
######################################################################
#
# Mark and police finger traffic on TCP source port 79.
ServiceCategories       tcp_79_svc
{
        MaxRate                 8         # kilobits
        MaxTokenBucket          32        # kilobits
        OutgoingTOS             00011100  # binary
        FlowServiceType         ControlledLoad
}

ServicePolicyRules      tcp_79_flt
{
        ProtocolNumber          6  # TCP
        SourceAddressRange      0.0.0.0-0.0.0.0 # Any IP src addr
        DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
        SourcePortRange         79-79
        DestinationPortRange    0-0             # Any dst port
        ServiceReference        tcp_79_svc
}
#
######################################################################
#
# Mark and shape ftp-data traffic on TCP source port 20.
ServiceCategories       tcp_20_svc
{
        MaxRate                 81920        # kilobits
        MaxTokenBucket          128          # kilobits
        OutgoingTOS             00011101     # binary
        FlowServiceType         Guaranteed
}

ServicePolicyRules      tcp_20_flt
{
        ProtocolNumber          6  # TCP
        SourceAddressRange      0.0.0.0-0.0.0.0 # Any IP src addr
        DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
        SourcePortRange         20-20
        DestinationPortRange    0-0             # Any dst port
        ServiceReference        tcp_20_svc
}
#
######################################################################
#
# LDAP server entry.
#ReadFromDirectory
#{
#   LDAP_Server             9.3.33.138  # IP address of LDAP server
#   Base                    o=ibm,c=us  # Base distinguished name
#   LDAP_SelectedTag        myhost      # Typically client hostname
#}
#
######################################################################

Loading Policies into IBM SecureWay Directory Server

If the policy daemon is used with the IBM SecureWay Directory LDAP Server, use the following schema as a guide to update /etc/ldapschema/V3.modifiedschema before starting the LDAP server. Refer to the LDAP server documentation for details.

LDAP Schema

objectClasses {
( ServiceCategories-OID NAME 'ServiceCategories' SUP top MUST
( objectClass $ SelectorTag $ serviceName ) MAY
( description $ FlowServiceType $ MaxRate $ MaxTokenBucket $ OutgoingTos ) )
( ServicePolicyRules-OID NAME 'ServicePolicyRules' SUP top MUST
( objectClass $ PolicyName $ SelectorTag ) MAY
( description $ DestinationAddressRange $ DestinationPortRange $
ProtocolNumber $ ServiceReference $ SourceAddressRange $ SourcePortRange ) )
}
attributeTypes {
( DestinationAddressRange-OID NAME 'DestinationAddressRange' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( DestinationPortRange-OID NAME 'DestinationPortRange' SYNTAX
 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( FlowServiceType-OID NAME 'FlowServiceType'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( MaxRate-OID NAME 'MaxRate' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( MaxTokenBucket-OID NAME 'MaxTokenBucket' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( OutgoingTos-OID NAME 'OutgoingTos' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( PolicyName-OID NAME 'PolicyName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( ProtocolNumber-OID NAME 'ProtocolNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( SelectorTag-OID NAME 'SelectorTag' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( ServiceReference-OID NAME 'ServiceReference' SYNTAX
 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( SourceAddressRange-OID NAME 'SourceAddressRange' SYNTAX
 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( SourcePortRange-OID NAME 'SourcePortRange' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
}

IBMattributeTypes {
( DestinationAddressRange-OID DBNAME ( 'DestinationAddressRange' 'DestinationAddressRange' ) )
( DestinationPortRange-OID DBNAME ( 'DestinationPortRange' 'DestinationPortRange' ) )
( FlowServiceType-OID DBNAME ( 'FlowServiceType' 'FlowServiceType' ) )
( MaxRate-OID DBNAME ( 'MaxRate' 'MaxRate' ) )
( MaxTokenBucket-OID DBNAME ( 'MaxTokenBucket' 'MaxTokenBucket' ) )
( OutgoingTos-OID DBNAME ( 'OutgoingTos' 'OutgoingTos' ) )
( PolicyName-OID DBNAME ( 'PolicyName' 'PolicyName' ) )
( ProtocolNumber-OID DBNAME ( 'ProtocolNumber' 'ProtocolNumber' ) )
( SelectorTag-OID DBNAME ( 'SelectorTag' 'SelectorTag' ) )
( ServiceReference-OID DBNAME ( 'ServiceReference' 'ServiceReference' ) )
( SourceAddressRange-OID DBNAME ( 'SourceAddressRange' 'SourceAddressRange' ) )
( SourcePortRange-OID DBNAME ( 'SourcePortRange' 'SourcePortRange' ) )
}

ldapSyntaxes {
}

matchingRules {
}

System Configuration

Overlapping Policies

Policies that overlap are installed in the QoS Manager in a nondeterministic ordering. In the case of overlapping policies the PolicyRulePriority attribute of the ServicePolicyRules should be specified to determine the ordering of enforcement of policies. The PolicyRulePriority attribute takes an integer as a parameter and, in the case of overlapping policies, the rule with the highest integer value is enforced.

UDP usage

Only connected UDP sockets are supported for QoS.

Policy Conflicts with RSVP Reservations

The policy and RSVP agents as mutually independent. Thus, care must be taken not to specify a policy that conflicts with, or is covered by, an existing RSVP reservation. In the presence of such conflicts, the system accepts the first policy or reservation while flagging a violation for the others.

Token Bucket Depth Specification

For correct operation, the MaxTokenBucket attribute must be set to at least the maximum MTU of all interfaces configured in the system.

Policy Modification

Policy modifications are handled by the policy agent by automatically deleting the existing policies and installing the new ones. This may result in a short, temporary window of time during which the corresponding traffic receives default (typically best effort) service.

Standards Compliance

This release is compatible with evolving Internet Engineering Task Force (IETF) standards for Differentiated (DiffServ) and Integrated Services (IntServ) on the Internet.

IntServ Model

The following RFCs describe various components of the IntServ model:

DiffServ Model

The following RFCs describe various components of the DiffServ model:

The following RFC outlines the current usage of the IP TOS octet:

The following RFCs outline future practices governing usage of the IP TOS octet:

IPv6 Support

QoS for AIX 5.2 only supports IPv4; IPv6 is not supported.

Controlling the Policy Daemon

You can control the policy daemon by using the system resource controller (SRC). For example, the command:

   startsrc -s policyd -a "-i 60"

starts the policy agent with a refresh interval of 60 seconds.

The command

   stopsrc -s policyd

stops the policy daemon.

Note
Stopping the policy daemon does not remove the installed policies in the kernel. When you start the policy daemon again, the old policies (previously installed in the kernel) are deleted, and the policies defined in the /etc/policyd.conf file are reinstalled.

The refresh SRC command is not currently supported.

QoS Reference

For important updates to this documentation, consult the README file in /usr/samples/tcpip/qos.

Commands

Methods

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]