Quality of Service

Previous Topic Next Topic

QoS ACS Logs

QoS ACS transactions (RSVP messages) can be collected by configuring the QoS ACS service logs. The QoS Admission Control accounting service and RSVP logging service log messages can be viewed in the Windows 2000 Server Event Viewer. These logs are more detailed and are recorded as fixed (not customizable) ASCII-format files that can be viewed with a text editor or converted to an open database connectivity (ODBC) database. Do not confuse QoS ACS logs with the default logging carried out by Windows 2000 Server (viewed by using the Event Viewer).

You can control a number of options for the creation of each type of log, including the directory in which the files are created, and whether to create single or multiple files. The log files are circular. When you specify a maximum file size, one of two things occur when that limit is reached:

You do not have to stop QoS ACS services to view log files. New log entries are generated whenever bandwidth is requested. This causes a progressive increase in log file size or in the number of log files. Therefore, you might need to balance the gathering of detailed data against the need to limit files to a manageable size and number. Extremely large log files can compromise performance because each file contains approximately 500 messages per megabyte. Additionally, smaller log files are easier for the administrator to search for specific events. Consider available disk space when setting log file sizes and monitor the storage space in use whenever using any logging features.

Accounting Logs

The accounting log information is useful for:

Accounting log information includes:

All fields in the log are terminated with a semicolon (;). Following is an example of an accounting log record:

1998/11/18 13:58:00:0578;192.168.3.5:4000[17];Start Sender;ENGR\Vincent;192.168.3.4:4000;New; 250000,1500,300000,10,1500

For accounting purposes, the most significant values in the entry show that the QoS Admission Control host approved a bandwidth request on November 18, 1998 (1998/11/18), at 1:58 P.M. (13:58:00:0578), which initiated a session (StartSender) with ID 192.168.3.4 and began sending data from a host in the Engineering (ENGR) domain for user Vincent.

Table 9.10 describes each field in the log.

Table 9.10 Log File Fields

Field Description
Date/time Date and time of the record, in Greenwich Mean Time (GMT).
Session IP addressing information The receiver's IP address, the port number on which the data is sent (following the colon), and the decimal protocol ID of the protocol used, enclosed in brackets ([ ]). To match protocol IDs with protocol names, see RFC 1700.
Record type One of the following: Start Sender, Start Receiver, Stop Sender, Stop Receiver, Reject Sender, or Reject Receiver.
User ID The domain and user name, preceded by a backslash (\), of the sender or receiver.
IP addressing information for the last hop The IP address of the last hop and either the port number on which the data is sent (following the colon) or the hexadecimal address of the network adapter (if the host relaying the message is a multihomed device). For example, 192.168.2-2.106:0x00000000.
Message status One of the following: New, Modify, Stop Sender reason, Reject Sender, or source IP address of the data flow.
Message detail Sender's traffic information, receiver's traffic information, Stop Receiver reason, and Reject Receiver reason.

Accounting and Billing

You can use information generated by the QoS ACS for accounting and billing. From the standpoint of network management, the accounting functions give you an overview of the ways in which your QoS resources are used. QoS ACS accounting shows you exactly who is using a resource, and for how long. Failed requests are also recorded, providing a record of who is trying to use QoS services without permission.

This information is available because QoS ACS servers log RSVP messages recording start and ending times of the flow, the resource requested and the user who is making the request. These records can be collected from the QoS ACS server and used to generate utilization reports for network managers. Alternately, these records can be processed to generate network usage billing.

RSVP Logs

You can configure the logging of RSVP messages. The RSVP log provides information similar to that of Network Monitor (NetMon). Using the log, you can trace who sends and receives RSVP messages and whether RSVP messages are accepted or rejected. This information is useful whenever QoS Admission Control Service–related network communication errors occur.

RSVP log information can help you troubleshoot by identifying:

In the RSVP log file, each field is terminated with a comma (,). A vertical bar (|) indicates the end of a group of traffic information. Following is an example of an RSVP log record:

1998/02/06 15:35:05, PATH ,192.168.3.6,4000,17,|,
192.168.3.5,0x00000000,|,30000,|,
192.168.3.4,4000,|,3.000E+004,1.50E+003,3.300E+004,10,1500,|,
0,0.000E+000,1500,1.#IOE+000

The most significant values in the entry show that on February 6, 1998, at 3:35 P.M., a PATH message originating on host 192.168.3.4 was sent to receiver 192.168.3.6.

Table 9.11 describes each item in the log in detail, showing the parameters that each message in the RSVP log contains.

Table 9.11 RSVP Log File Fields

Field Description
Date/time Date and time of the message, in Greenwich Mean Time (GMT)
Type of message PATH, RESV, PATH-ERR, RESV-ERR, PATH-TEAR, or RESV-TEAR, with additional parameters:

Confirmation request: RESV-CONF or No RESV-CONF, indicating whether the receiver wants a reservation confirmation.

Scope: An explicit list of sender hosts (in wildcard reservation-style format) toward which the information in the message is forwarded.

Reservation style: Determining whether resources are reserved by fixed filter, share explicit, or wildcard. For more information about these styles, see RFCs 2205, 2210, 2215, and 2216.

For detailed information about these parameters, see RFC 2205.

Session IP addressing information The receiver's IP address, the port number on which the data is sent, and the decimal protocol ID of the protocol used, followed by a vertical bar (|). For a list matching protocol IDs with protocol names, see RFC 1700.
IP addressing information for the last hop Either the IP address of the last hop and the port number on which the data is sent (following the colon), or the hex address of the network adapter if the host relaying the message is a multihomed device, followed by a vertical bar (|).
Refresh interval The frequency at which, in milliseconds, this message is sent.
Sender IP addressing information The sender's IP address, the port number on which the data is sent, and the decimal protocol ID of the protocol used, followed by a vertical bar (|).
Bucket rate The bucket data rate.
Bucket size The size of the bucket in which packets are grouped for transmission. For more information on packet buckets, see RFCs 2210, 2215, and 2216.
Peak rate The burst rate of the packets.
Packet size The minimum packet size for transmission.
MTU size The maximum packet size for transmission, followed by a vertical bar (|). This field, plus the previous four fields, make up the Tspec (traffic parameters for the flow). For more information on the Tspec, see RFCs 2205, 2210, 2215, and 2216.
Adspec The remaining fields in the record indicate the traffic parameters for the receiver.

© 1985-2000 Microsoft Corporation. All rights reserved.