I would like to monitor the quality of a network connection with the QoS Round Trip sensor. Is it necessary to install a remote probe on the target, i.e., at the “end” of the connection, or is there another option to send the UDP packets for quality of service measurements to?
This article applies to PRTG Network Monitor 14.x.12 or later
QoS Round Trip Monitoring Without Remote Probes
In general, PRTG measures the Quality of Service (QoS) of a connection by sending UDP packets from one end of the connection to the other end of the connection. Regarding the QoS (Quality of Service) Round Trip sensor, the traffic packets are sent back from the end of the line to the source and the sensor measures various QoS parameters of this packet round trip.
Because it is mandatory to have two endpoints for QoS measurements, you need a reflector for the UDP packets at the target. You can use a remote probe at the connection end for this purpose, or you can use the PRTG QoS Reflector. The source of the packets is a device that you added to PRTG.
QoS Reflector for the QoS Round Trip Sensor (Open Source)
The PRTG QoS Reflector is a Python script that bounces all incoming UDP packets. Because of this, you can use it as QoS endpoint on a device that you plug in at the end of the connection you want to measure, for example, on a small Raspberry Pi.
The main advantages of the PRTG QoS Reflector in comparison to a remote probe for QoS monitoring are the quick setup and that it is compatible with any platform that runs a Linux based operating system, so you do not need a Windows device at the connection end. We provide the QoS Reflector as open source project on GitHub. Please follow the steps below to set up the reflector for a QoS Round Trip sensor.
- The PRTG QoS Reflector currently does not support the QoS (Quality of Service) One Way sensor.
- This is an experimental feature. Currently, it is in beta status. The methods of operating can change at any time, as well as the available settings. Do not expect that all functions will work properly, or that this feature works as expected at all. Be aware that this feature can be removed again from PRTG at any time.
- This article is provided for your information only. The steps described here have been tested carefully. However, we cannot offer deep technical support for customizing this script nor for writing your own scripts.
You need to fulfill the following requirements on the device on which you want to use the QoS Reflector as connection endpoint:
- Any Linux based operating system
Note: Although originally written for Linux systems, you can use the QoS Reflector on Windows systems as well with minor changes to the script.
- Python 2.7 or later: see python.org Furthermore, you need a PRTG core server version 14.x.12 or later to use a QoS Round Trip sensor with the reflector.
Please follow the steps below to measure the quality of service of a connection with the PRTG QoS Reflector.
1) Prepare and call the script
Basically, you just have to copy the QoS Reflector script to a device at the connection target and execute it.
- Download the QoS Reflector package from GitGub and copy it to your Linux distribution.
- Note: If you want to set up the QoS Reflector on a Raspberry Pi, give the Raspberry Pi a static IP address and put qosreflect.py on the root of the storage system.
- Make the file qosreflect.py executable. E.g., use the following command:
chmod 755 qosreflect.py
- Optionally, create a config file qosreflect.conf with the following content:
host:All port:50000 replyip:None
- Execute the script:
./qosreflect.py [-h] [-p PORT] [-c CONF] [-o HOST] [-r REPLYIP] [-d]
- Note: On a Raspberry Pi, we recommend you to set the QoS Reflector script to boot at startup.
We recommend you to use parameters with the script call. This enables you run several instances of the QoS Reflector. The following parameters are available:
|--port PORT||Provide the port number as defined for the respective QoS Round Trip sensor in PRTG.|
|--host HOST||Provide the IP address of the interface you want the script bind to. We recommend you to use All to bind all available interfaces.|
|--replyip REPLYIP||Optional: Provide the IP address of the PRTG probe that sends the UDP packets. The reflector will only reply to this IP address.|
|--conf CONF||Optional: Use this parameter only if you do not use the port and host parameters in the command. Then the script will use parameters as defined in your config file. Provide the path to the config. |
If you do not provide this argument, the default config file qosreflect.conf will be used.
|--debug||Optional: Set this argument to get detailed debug output.|
|--help||Use this argument to show all available parameters.|
./qosreflect.py --port 50000 --host All
2) Add a QoS Round Trip sensor to PRTG
If you have not created a QoS (Quality of Service) Round Trip sensor yet, do so now.
- Add the QoS Round Trip sensor to a device on any probe, depending on what connection you want to monitor.
- In the sensor settings, choose the option Custom Target for QoS Target.
- In the Target Host/IP field, enter the IP address of the machine on which you run the QoS Reflector script.
- The Port number has to match the port you use for calling the script (either the argument or the config file definition).
- You can leave all the other settings unchanged.
QoS Round Trip Sensor: Settings
Done! Wait a few moments and the sensor will show you its QoS measurements for the connection to and from the target device.
QoS Round Trip Sensor Monitors a Connection to a QoS Reflector
QoS Reflector on Windows Systems
One of our customers successfully runs the QoS Reflector on Windows systems.
- In the QoS Reflector script, remove the first line that defines the interpreter:
- Run the QoS Reflector from the command line and specify the Python interpreter as the application:
<your_path>\Python27\python.exe reflector.py --port 50000 --host All
- Configure your QoS Round Trip sensor as described above.
Thank you, Jordan, for sharing this information!
If you encounter any issues with your QoS Reflector, call the script with the parameter -d or --debug to get detailed information.
Would be great to have this (reply function) interacting with Cisco IP SLA responder.
Please allow me to ask you to clarify what exactly you mean.
We already have an SLA sensor:
We also have two QoS sensors:
Are you missing any functions?
Hi Having a few problems with this, which has been fine up till now! Before, we have been using Neorouter as a VPN between the server and the QoS reflector-which is a Raspberry Pi, the server is a WIN7 Pro machine. Worked great. Now we have decided to open up both firewalls at each end, and use the QoS script in the "raw", so to speak, to see if any improvement is made (due to VPN overhead etc). For the life of me,I cannot get it to work-both the Pi is DMZ'd (it sits behind a NAT's router in a remote site) and the Windows server is also DMZ'd. The script works, as if I set up another server on the same local network as the Pi sits on, the server comes back all "green". The Windows firewall is off as well.If I move it all back to going across the VPN, it all starts working again! I can only think the UDP packets as being lost somewhere, without the VPN in place.If a put in place a Port Monitor sensor (RDP 3899) or a ICMP ping, these all work as well! It only seems to be the QoS script that has the problem?
without knowing your infrastructure troubleshooting is hard in your scenario.
Do you have any device in place which has a UDP flood protection which is configured? Best regards
I'd like a little clarification on how the probe generates udp packets from its monitored device. I cannot guarantee qos markings from my probe to an end point, and I'd rather have two endpoints measure qos between each other. They are both linux so I'd prefer to have a mini probe on one end and the reflector on the other end, and the results sent back to the prtg probe/core. Is this possible?
Unfortunately, this is not possible. This functionality is not implemented in the source code of a mini probe. You will have to use either a local probe or remote probe.