# Network Delay Time monitor

This section explains how to define the Network Delay Time server whose resources you want to monitor, and to select the counters to monitor.

In this topic:

## Network monitoring overview

Network configuration is a primary factor in the performance of applications. A poorly designed network can slow client activity to unacceptable levels.

You use Network monitoring to determine whether your network is causing a delay in the performance test. You can also determine the problematic network segment.

In a true Web or client/server system, there are many network segments. A single network segment with poor performance can affect the entire system.

The following diagram shows a typical network. To go from the server machine to the Vuser machine, data must travel over several segments.

The Network Delay Time monitor shows the delays for the complete path between the source and destination machines (for example the database server and Vuser host). The graph maps the delay as a function of the elapsed performance test time. Each defined path is represented by a separate line with a different color in the graph.

To measure network performance, the Network monitor sends packets of data across the network. When a packet returns, the monitor calculates the time it takes for the packet to go to the requested node and return. This time is the delay which appears in the Network Delay Time graph.

Note: The delays from the source machine to each of the nodes are measured concurrently, yet independently. It is therefore possible that the delay from the source machine to one of the nodes could be greater than the delay for the complete path between the source and destination machines.

Back to top

## Set up the network monitoring environment

This task describes how to set up the monitoring environment for the Network Delay Time monitor.

1. Prerequisites

   - To enable network monitoring, you must install the LoadRunner Enterprise agent on the source machine. You do not have to install the LoadRunner Enterprise agent on the destination machine.

   - To run the Network monitor, you must have administrator privileges on the Windows source machine (unless you are using the ICMP protocol).

2. Configure the Linux source machine - optional

   You can run the Network monitor on Linux source machines, using UDP or ICMP. Before running the Network monitor from a Linux source machine, configure the source machine. For task details, see Configure the Linux source machine for network monitoring.

3. Configure the firewall between the source and destination machines - optional

   If you are monitoring a network in which there are firewalls between the source and the destination machines, you must configure the firewalls to allow the network data packets to reach their destinations.

   - If you are using the TCP protocol, the firewall that protects the destination machine should not block outgoing ICMP_TIMEEXCEEDED packets (packets that are sent outside the firewall from the machine). In addition, the firewall protecting the source machine should allow ICMP_TIMEEXCEEDED packets to enter, as well as TCP packets to exit.

   - If you are using the ICMP protocol, the destination machine's firewall should not block incoming ICMP_ECHO_REQUEST packets, or outgoing ICMP_ECHO_REPLY and ICMP_ECHO_TIMEEXCEEDED packets. In addition, the firewall protecting the source machine should allow ICMP_ECHO_REPLY and ICMP_ECHO_TIMEEXCEEDED packets to enter, and ICMP_ECHO_REQUEST packets to exit.

   - If you are using the UDP protocol, ensure that the UDP protocol can access the destination machine from the source machine. The destination machine's firewall should not block outgoing ICMP_DEST_UNREACHABLE and ICMP_ECHO_TIMEEXCEEDED packets. In addition, the firewall protecting the source machine should allow ICMP_DEST_UNREACHABLE and ICMP_ECHO_TIMEEXCEEDED packets to enter.

   Note: To run the Network Delay monitor when there are firewalls between the Controller and the source machine, you must configure the LoadRunner Enterprise agent, MI Listener, and Network Delay monitor for monitoring over a firewall.

4. Configure the monitor as described in Configure the Network Delay Time monitor.

Back to top

## Configure the Network Delay Time monitor

This task describes how to configure the Network Delay Time monitor.

1. From the LoadRunner Enterprise navigation toolbar, click and select Monitors (under Assets).

2. In the test resource tree, select an existing monitor profile, or click New Monitor Profile and create a new monitor profile.

3. In the Monitor Profile page, click Add Monitor and select Network Delay Time.

4. In the Network Delay Time page, enter the server details:

   UI Elements | Description
   --- | ---
   Source Machine | The name of the source machine from which you want the network path monitoring to begin. To run the Network Delay Monitor when there are firewalls between the LoadRunner Enterprise Host machine and the source machine, type the server name or IP address of the source machine according to the format: `<MI Listener machine>:<source machine local key>` Where `source machine local key` is the unique key that you chose when configuring the LoadRunner Enterprise agent on the source machine. Example: 12.12.12.3:vds When working with Over Firewall (OFW) load generators or monitors, the `<source machine local key>_<location>` is mandatory. The OFW machine must also be added as a host in LoadRunner Enterprise Administration. For details, see Specify MI Listeners. For details about working with firewalls in LoadRunner Enterprise, see the firewall section in the LoadRunner Enterprise Installation Guide.
   Platform | The platform on which the machine runs.
   Destination Machine | The name of the machine at the final destination of the path you want to monitor. Note: If the destination machine is localhost, type the local machine's name and not localhost.
   Monitor Settings | Send Request Using X protocol. Select the relevant protocol. It is recommended that you keep the default protocol. In Windows, the default is TCP, and in UNIX, the default is UDP. Send request to port X. Enter the port number being used by the network path. Enable display of network nodes by DNS names. Select to view the DNS name of each node along the network path, in addition to its IP address. Note that selecting this option decreases the speed of the Network monitor.
   Monitor Frequency | Send next packet X milliseconds after receipt of previous packet. Select the number of milliseconds the monitor should wait between receiving a packet and sending out the next packet. If you have a long, steady performance test, you can increase the interval by several seconds. Default: 3000 milliseconds
   Monitoring Packet Retries | Wait X seconds for packet to return before retrying. Select the maximum number of seconds that the monitor should wait for a packet to return before it retries to send the packet. Default: 3 seconds. If your network is very large and loaded (an internet connection with a low capacity), increase the value by several seconds. If you have a small network (such as a LAN), decrease the value. Number of retries. Select the number of times the Network monitor should try resending a packet to a node if the packet is not initially returned. Default: 0

Back to top

## Network Delay Time graph

The Network Delay Time graph shows the delay for the complete path between the source and destination machines (y-axis) as a function of the elapsed performance test time (x-axis).

Each path defined in the Add Destination Machines for Network Delay Monitoring dialog box is represented by a separate line with a different color in the graph.

Back to top

## Notes and limitations

This section describes troubleshooting for the Network Delay Time monitor.

If monitoring is unsuccessful and LoadRunner Enterprise cannot locate the source or destination machines, make sure that the specified machines are available to your machine. Perform a "ping" operation. At the command line prompt, type `Ping server_name.`

To check the entire network path, use the trace route utility to verify that the path is valid.

For Windows | Type `tracert <server_name>`
For UNIX | Type `traceroute <server_name>`

If the monitoring problem persists once you verify that the machines are accessible and that the network path is valid, perform the following procedures:

1. If you are using the TCP protocol, run <LoadRunner Enterprise root folder>\bin\webtrace.exe from the source machine to determine whether the problem is related to the Controller, or the WebTrace technology on which the Network Delay monitor is based. If you are using the UDP or ICMP protocols, the problem must be related to the Controller and not WebTrace, since these protocols are not WebTrace technology-based.

2. If you receive results by running webtrace.exe, the problem is related to the Controller. Verify that the source machine is not a UNIX machine, and contact the Customer Support Web site with the following information:

- the Controller log file, drv_log.txt, located in the temp directory of the Controller machine.

- the traceroute_server log file, located on the source machine.

- the debug information located in the TRS_debug.txt and WT_debug.txt files in the path directory. These files are generated by adding the following line to the [monitors_server] section of the <LoadRunner Enterprise root folder>\dat\mdrv.dat file, and rerunning the Network monitor:
  `
  ExtCmdLine=-traceroute_debug path`

3. If you do not receive results by running webtrace.exe, the problem is related to the WebTrace technology, on which the Network Delay monitor is based. Perform the following procedures on the source machine:

- Verify that the packet.sys file (the Webtrace driver) exists in the WINNT\system32\drivers directory.

- Check whether a driver (such as "Cloud" or "Sniffer") is installed on top of the network card driver. If so, remove it and run WebTrace again.

- Verify that there are administrator permissions on the machine.

- Using `ipconfig /all`, check that only one IP address is assigned to the network card. WebTrace does not know how to handle multiple IP addresses assigned to the same card (IP spoofing).

- Check the number of network cards installed. Run `webtrace –devlist` to receive a list of the available network cards.

- If there is more than one card on the list, run `webtrace -dev <dev_name> <destination>`, where `<dev_name>` is one of the network card names shown in the list. If you discover that WebTrace is binding to the wrong card, you can use `webtrace set_device <dev_name>` to set a registry key that instructs WebTrace to use a specified card instead of the default one.

- Verify that the network card is of the Ethernet type.

- Contact the Customer Support Web site with the output of `webtrace.exe –debug` (for example, `webtrace.exe –debug www.merc-int.com`) and `ipconfig /all` on the machine.

Back to top

See also:

- Monitors

https://admhelp.microfocus.com LoadRunner Enterprise 8942
Tips to improve your search results... LoadRunner Enterprise Help Center LoadRunner Enterprise Help LR Enterprise Help 2020_SP2-SP3 All View Local Help Center View Online Help Center back Go back in browser history forward Go forward in browser history Remove search highlights next topic Go to next topic previous topic Go to previous topic Print the current topic Version: