Tools

This section describes various tools and their roles in troubleshooting QoS implementations. Certain tools are described only briefly; for further details, see the Microsoft ® Windows ®  2000 Resource Kit Tools ** Help.

PathPing

This TCP/IP utility has new functional parameters related to QoS:

-t

If packets are sent with an 802.1p tag, during the transition between a 802.1p aware network and network that is not 802.1p–aware, the switch connecting these two networks may be configured to strip out the tag before forwarding the packets onto the non-802.1p–aware network. Otherwise, non-802.1p–aware devices which cannot recognize the tag may discard the packet, wrongly assuming that it was a corrupted. Enabling this parameter sends the packets with a tag that identifies the network element that is tossing the tagged packet.

-r

This switch tests whether each node in the path is RSVP-aware. A node is considered RSVP-aware if it responds to a protocol 46 message (or times out). It is considered non-RSVP–aware if it sends an ICMP protocol unreachable error message. Note that if the RSVP service is not running on the node, it will return an ICMP Protocol unreachable error message.

For more information about PathPing, see "TCP/IP Troubleshooting" in this book.

Wdsbm

This tool identifies the QoS ACS that manages the segment to which a specific host is attached.

wdsbm -i <local interface IP address>

Wdsbm prints information (including the IP address) that pertains to the QoS ACS that is intercepting RSVP messages to and from the specified interface. Since the QoS ACS can block RSVP messages, it is useful to know the IP address of the QoS ACS when attempting to isolate the location at which RSVP messages are blocked.

Rsvptrace

Rsvptrace generates a log of RSVP messages that are sent and received by the RSVP SP on a host. The tool also shows API calls from sending and receiving applications to the RSVP SP. By running Rsvptrace on the sender and receiver, it is easy to verify that applications are making the required calls to the API, the RSVP SP is generating RSVP messages, and the messages are arriving from the network. Rsvptrace can be run on the QoS ACS to inspect received and transmitted RSVP messages. However, since QoS ACS servers do not run multimedia applications, no API entries will appear in the trace.

To enable RSVP tracing on a host, add the entry EnableTracing to the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RSVP \Parameters

with a data type of REG_DWORD. Set the value of the entry to 0x1.

The RSVP service must be restarted after this entry is added to the registry. Use Computer Management to restart the RSVP service.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

The RSVP service must be restarted after this value is added to the registry. Use the Computer Management interface to restart the RSVP service.

The RSVP SP begins generating the Rsvptrace log in the directory % windir % \system32\logfiles .

Log files are named RsvpTrace XX .txt, where " XX " is a number from 00 to 09. Each log file is limited in size. When a log file fills up, another one is created using the next sequence number for the " XX " part of the log file name. Once the last log file sequence number is used and the last log file is filled, the first log file is overwritten. The user should inspect the list of log files and their creation dates to see which log file is currently being written.

The user can monitor data being written to the log file in real time by typing:

tail -f RsvpTrace XX .TXT

where " XX " is the trace-file number.

Following is a sample from a sender's Rsvptrace log:

1999/04/20 17:53:42:0679; From API; PATH ;172.31.8.159,5003,17;0.0.0.0,0x00000000;30000;172.31.3.21,3128;1.028E+0

1999/04/20 17:53:42:0679; 172.31.8.159 <= 172.31.3.21; PATH ;172.31.8.159,5003,17;172.31.3.21,0x00000000;1500;172

1999/04/20 17:53:44:0679; 172.31.8.159 <= 172.31.3.21; PATH ;172.31.8.159,5003,17;172.31.3.21,0x00000000;3000;172

1999/04/20 17:53:46:0773; 172.31.8.159 <= 172.31.3.21; PATH ;172.31.8.159,5003,17;172.31.3.21,0x00000000;6000;172

1999/04/20 17:53:54:0617; 172.31.8.159 <= 172.31.3.21; PATH ;172.31.8.159,5003,17;172.31.3.21,0x00000000;12000;17

1999/04/20 17:54:07:0664; 172.31.8.159 <= 172.31.3.21; PATH ;172.31.8.159,5003,17;172.31.3.21,0x00000000;24000;17

1999/04/20 17:54:12:0601; 172.31.3.1 => 172.31.3.21; RESV ;172.31.8.159,5003,17;172.31.3.1,0x00000000;30000;No Re

1999/04/20 17:54:12:0679; From API; PATH ;172.31.8.159,5003,17;0.0.0.0,0x00000000;30000;172.31.3.21,3128;1.028E+0

1. The first entry shows that at 17:53:42:0679, the sending application invokes the QoS API, which transmits a PATH message.

2. The next entry shows the PATH message transmitted to the network. There is no guarantee that it is actually sent to the network, but it does verify that the RSVP SP has passed the message to the TCP/IP stack for transmission to the network.

3. Additional PATH messages are sent to the network. Messages are refreshed at 30-second intervals.

4. At 17:54:12:0601, a RESV message arrives at the sender for the session, completing the reservation process. This indicates that the PATH message arrived at the end node (receiver) and the receiver responded with a RESV message.

5. At 17:54:12:0679, another API PATH is logged. This indicates that a proxy for the application (in the RSVP SP) is refreshing the RSVP state on behalf of the application.

The IP addresses in the PATH message log entries show that the RSVP session is 172.31.8.159 and the sender is 172.31.3.21. The session address is equivalent to the receiver address in the case of unicast, and to the multicast session address in the case of multicast.

The IP addresses in the RESV message entry show that the RESV message is sent to the sender at IP address 172.31.3.21. However, it shows that the RESV message arrives from the previous hop—172.31.3.1—which is the IP address for the router that sent the RESV message to the sender.

Netmon

Network Monitor (Netmon) monitors traffic on a network. Versions of Netmon later than version 2 include RSVP-parsing functionality. Netmon can also monitor 802.1p tagging.

Netmon can be run on the sending host, the receiving host, QoS ACS servers and on intermediary hops. Netmon requires installation. For information about installing Netmon, see the Windows 2000 Server Help.

Running Netmon on a Host

Generally, Netmon needs to be run on a computer that is used strictly as a traffic monitor, as opposed to end nodes or QoS ACS servers (any hosts that generate RSVP messages). It is also important that the monitoring computer is not attached to the network by use of a dedicated port on a learning bridge type switch (most modern chassis-based switches). Otherwise, the switch can prevent the monitoring computer from seeing traffic that is not addressed to it specifically. Generally, smaller, cheaper hubs do not act as learning bridges and flood traffic from each port to all other ports. Use this type of hub to attach the monitoring computer to the same switch port as the next or previous hop.

Installing and using Netmon on both the sender and receiver is recommended.

Capture and Display Filters

Set a capture filter for all messages to and from the end node. The capture needs to be started on each node before the sending application is started. RSVP messages are typically refreshed every 30 seconds; take this into account when deciding how long to let the capture run.

Once the capture is complete, use the display filter to extract RSVP messages only from the captured data. Traces of RSVP messages should indicate a PATH message sent by the sender, arriving some time later at the receiver. The receiver responds with a RESV message, which arrives at the sender. If the traces do not confirm this behavior, one or both of the message types might have been dropped in transit or were not generated by the end node. As long as the application is running, no PATH-TEAR or RESV-TEAR messages display in the trace. PATH-TEAR or RESV-TEAR messages might indicate that one of the application peers has terminated, or that a RSVP-aware network node has rejected a request.

Monitoring 802.1p

To monitor 802.1p tags, copy the Parser.dll ** file from the Microsoft® Windows® 2000 Resource Kit Tools Help tools directory to the root directory of your Netmon installation directory. Next, copy the Mac.dll file ** from the same tools directory to the Parsers ** subdirectory under your Netmon installation directory. Once these files have been copied, restart Netmon.

Netmon only reveals 802.1p tags if it is run on a host that does not have 802.1p-capable drivers (or on which 802.1p functionality has been disabled). Drivers that are 802.1p-capable strip off the 802.1p tags before handing the packets to Netmon.

Rsping

Rsping determines whether a specific network path is blocking RSVP signaling messages. If you suspect that certain RSVP messages are not arriving at their intended destination, Rsping can detect if the network is at fault. Unlike Rsvptrace, which allows the user to observe RSVP messages arriving at or generated from a specific node, Rsping enables the user to generate ** specific styles of RSVP messages for transmission to an RSVP peer.

Both PATH and RESV messages are generated when Rsping is run. It is also possible to specify:

• If these messages are multicast or unicast.

• Intserv service type.

• Flow rate.

With Rsping, multicast RESV messages use the wildcard filter (WF) style, while unicast messages use the fixed filter (FF) style. In addition, the peak rate requested is always twice the flow rate specified.

Invoke Rsping using the parameters that most closely emulate the RSVP messages generated by the real application. These messages can be observed by inspecting the Rsvptrace file on the transmitting host.

Tcmon

Tcmon is a traffic control monitor that can be used to:

• Verify the creation of kernel traffic flows.

• Identify characteristics and statistics associated with interfaces (such as whether or not 802.1p is enabled).

• Identify characteristics and statistics associated with each flow (such as service type, tagging or marking in effect, bytes transmitted on the flow, and so on).

For example, the Microsoft® NetMeeting® video conferencing application creates a single flow for audio traffic and another flow for video traffic. These should both be visible by using Tcmon (invoke Tcmon for the appropriate transmit interface and to set it to Auto Refresh mode). In addition, Tcmon indicates a third flow for the Network Control service type. This flow is for RSVP signaling traffic and remains active as long as RSVP is active.

Initially, Tcmon reports that the two traffic flows created on behalf of the application are the best-effort ** service type. The service type remains best-effort ** until the network approves the sender's RSVP request. At that time, traffic control is invoked and the flow's service types change to controlled load or guaranteed. If this does not happen, then either the network has not confirmed the QoS request, or a problem exists with local traffic control or the RSVP SP.

To install Tcmon, run Setup.exe from the Tcmon Install directory on the Resource Kit Tools Help.

To run Tcmon, at a command line type:

tcmon

The Tcmon dialog box appears. Select the appropriate interface for which traffic control is to be monitored. When looking for changes in flow parameters (such as changes in service type), it is helpful to enable the Auto Refresh ** mode (on the Refresh menu of the Tcmon dialog box).

System Monitor

System Monitor (Sysmon) monitors traffic control, RSVP, and QoS ACS components. It is a standard component of Windows 2000. See the Windows 2000 Server Help for instruction on running System Monitor.

Once System Monitor is active, from the Add Counters ** dialog box:

• Select Psched Pipe** to monitor traffic control parameters such as number of flows installed and number of packets queued in various QoS Packet Scheduler components.

• Select QoS ACS / RSVP Service** to monitor parameters such as API calls and RSVP messages.

Qtcp

Qtcp measures end-to-end network integrity and service quality for QoS verification. Qtcp sends a sequence of test packets through a network and reports on the queuing delay experienced by each packet. Packets that do not arrive at the destination are recorded as dropped packets.

Qtcp performs the following:

1. Reports precise microsecond delay variations.

2. Invokes network QoS by default, and is useful for evaluating QoS mechanisms.

3. Can simulate traffic flows for a range of user-selected packet sizes.

4. Can simulate traffic flows shaped to a specific range of token bucket parameters.

5. Can be used on an isolated, controlled network, or on a production network.

6. Generates detailed result logs.

A Qtcp session is invoked on both sending and receiving hosts. Qtcp uses the GQoS API to invoke QoS from local traffic control and from the network. The Qtcp sender causes an RSVP PATH message to be sent towards the receiver and waits until a response is received. The Qtcp receiver waits for an RSVP PATH message from the sender and responds by transmitting an RSVP RESV message.

Receipt of the RESV message at the sender initiates the measurement phase. At this time, the sender submits buffers to the kernel for transmission. The kernel paces the transmission of traffic according to the token bucket parameters and service type selected by the user. As packets are transmitted, the sequence number and the local time (to a precision of 100 nanoseconds) is recorded on each packet.

When packets arrive at the receiver's traffic control, the local time of the receiving host is recorded in each packet, and traffic control passes the packets to the receiving Qtcp peer. The receiving Qtcp peer process maintains a list of all received packets, including the packet sequence number, the time sent, and the time received.

The sending portion of the test terminates on the sending side when the transmitter has sent the required number of packets (the default of 2,048 packets can be overridden). Following the transmission of the last packet, the sender sends a terminating sequence of 10 termination packets. The test terminates on the receiving side upon receipt of a termination packet, or upon receipt of the required number of packets. On particularly congested links, the receiver might never receive the required number of packets, because the termination packets can be dropped. In this case, the Qtcp receiver can be manually terminated by typing:

q

Upon termination, the receiver Qtcp parses and processes the log of received packets. Three logs are generated:

• < File_name >.sta contains summary statistics. It reports the total number of packets received and specifies the sequence number of each dropped packet.

• < File_name >.raw contains a detailed log showing normalized send time and receive time for each packet, the latency (difference between sent and received time), packet size and sequence number.

• < File_name >.log is a result of normalizing the results of the second file to account for any clock discrepancies between the two hosts. Normally, this is negligible, but on lightly loaded, high-speed LANs it can be significant.

To run Qtcp on the sender, at a command line type:

qtcp –l 64 -t < IP Address >

where 64 is the buffer size in bytes, and < IP Address > is the IP address of the receiver. The following is displayed:

Initiated QoS connection. Waiting for receiver.

To run Qtcp on the receiver, at a command line type:

qtcp -f < filename > –r

The following is displayed:

Waiting for QoS sender to initiate QoS connection.

The receiver and the sender await the required exchange of RSVP messages before starting the data transfer. By default, kernel traffic control paces transmitted packets at a rate of 100 KBps (kilobytes per second).

Qtcp displays a series of dots on the node consoles. Each dot corresponds to 100 packets sent or received. The first dot is printed on the receiver prior to the actual receipt of the first 100 packets. The dots indicate that Qtcp is functional.

Upon transmission of the specified number of packets, the sender terminates with a message regarding the transmission rate. Next, upon receipt of the required number of packets (or termination packets), the receiver terminates with the message

Received 2048 buffers.

followed by statistics. However, these statistics might not be accurate. Use the File_name .sta, File_name .raw and File_name .log files to view the session statistics.

To generate the Qtcp log files, press the ENTER key on the receiver console after the session terminates.

Readpol

Readpol displays the QoS ACS policies that are in effect within a particular domain. Readpol provides a method of identifying the policies that apply to a particular user without using the QoS ACS console or having administrator privileges. Readpol is particularly useful in tracking the propagation of PATH or RESV messages when the QoS ACS is suspected of blocking these due to restrictive policies.

Rsvpsm

Rsvpsm is an interactive tool that allows the user to query the status of RSVP sessions on a remote computer. Information available by use of Rsvpsm includes all PATH state blocks, RESV state blocks, and Traffic Control state blocks ** maintained by a remote host.

This tool can be used to track complex RSVP problems spanning multiple hosts.

Qossp.aid, Rapilib.aid

Qossp.aid and Rapilib.aid generate diagnostic output from the RSVP SP. These tools are particularly useful for tracking problems with an application's use of the QoS API, or with the RSVP SP itself.

To enable RSVP SP logging, add the registry entry EnableDebugAid to the following subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RSVP \Parameters

with a data type of REG_DWORD.

To enable RSVP SP debugging related to an application's use of the API, set the least significant bit of the value (bit 0) to 1 .

To enable diagnostic output regarding the internal functioning of the RSVP SP, set the 2nd least significant bit of the value (bit 1) to 1 .

Use Computer Management to restart the RSVP service in order to initiate RSVP SP logging.

The RSVP SP logs are stored in the directory % windir %\system32\logfiles. Files are generated for each application that makes use of the RSVP SP. Log files named QoSSP.aid.< XXXX > are generated when bit 0 of the registry value is set to 1 Log files named rapilib.aid.< XXXX > ** are generated when bit 1 is set to 1. In each case, < XXXX > is the process ID of the application.

Ttcp

Ttcp is a noise generation tool. The effects of QoS are very noticeable when resources are scarce (some part of the network is congested). To test QoS deployments, it is helpful to artificially congest a network in a controlled manner by generating multiple simultaneous conversations, and generating traffic with a packet size distribution that mimics the traffic pattern in your production network.

Ttcp generates a single UDP or TCP session between two hosts. Buffer size, number of buffers, ports used, and other miscellaneous parameters can be set and controlled. It is not possible to control the rate at which the transmitter sends (other than by using the QoS Packet Scheduler and Tcmon to create a shaped flow for the Ttcp traffic). A single conversation is generated for each instance of Ttcp. Multiple conversations can be established by invoking multiple instances of Ttcp.

To induce Ttcp to drive the network more aggressively, invoke it by use of the -a and -c options.

Tracert

Tracert determines the route to a destination by sending Internet Control Message Protocol (ICMP) echo packets with varying Time to Live (TTL) values. Each router along the path is required to decrement the TTL on a packet by at least 1 before forwarding it. When the TTL on a packet reaches 0, the router is supposed to send back an ICMP Time Exceeded message to the source system. The Tracert usage is:

tracert [ -d ] [ **-h <**maximum_hops> ] [ **-j <**computer-list> ] [ **-w <**time-out> ] **<**target_name> <receiver IP address>

Tracert Parameters

-d

Specifies not to resolve addresses to computer names.

-h < maximum_hops>

Specifies maximum number of hops to search for target.

-j < computer-list>

Specifies loose source route along < computer-list> .

-w < time-out>

Waits the number of milliseconds specified by < time-out> for each reply.

<target_name>

Name of the target computer.

<receiver IP address>

Causes the sending host to print the IP addresses for a single interface on each router that exists along the path from sender to receiver. This list is helpful in identifying nodes that might be dropping or blocking RSVP messages or data.