What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

QoS (Quality of Service) Round Trip test fails

Votes:

0

I want to double check, if the following scenario with NAT on both sides is supported. Topology:

SJ-Win-Probe1 10.10.20.20 --- Cisco Router with Public IP  63.x.y.z ----- public internet ------- AWS IGW Public IP 3.a.b.c --- Win-Probe2 10.53.1.20

Cisco Router is doing static NAT, mapping all ports 1:1 between 10.10.20.20 and 63.x.y.z. Both remote probes are registered successfully, ping, health, windows-related sensors are working fine. QoS (Quality of Service) One Way works also good. The problem is with round trip test, which we need for MOS score - it is failing. Round trip sensor is defined with PRTG probe AWS using public IP 3.a.b.c

Sensor is failing with the following message:
"This sensor has not received any data since startup. There seems to be a problem with the UDP port of the Qos Sensor (Port 50000 already in use?)."

Did wireshark traces on both sides. SJ-Win-Probe1 sends packets out, wireshark traces on AWS shows packets arriving on UDP 50000 port with source of Cisco Router 63.x.y.z and destination 10.53.1.20. The AWS-Win-Probe2 does NOT sends ANY packets back.

Potential reason: AWS-Win-Probe2 has the public IP 3.a.b.c (elastic IP from AWS assigned to the Ethernet interface), but the AWS-Win-Probe2 has private IP 10.53.1.20 configured on the NIC. This is the normal configuration on AWS - the IGW is connected to this VPC and they do 1:1 NAT between public 3.a.b.c. and private 10.53.1.20.

Questions:

  • is the round trip test supported in such topology?
  • why the Endpoint2 does not reply back to the Endpoint1?
  • can we have a quick meeting in order to troubleshoot it? I am based in San Jose, we have 9 hours time shift to Germany, wir koennen auch Deutsch reden. :-)

Thanks!!

mos remote-probe round-trip

Created on Aug 3, 2019 6:56:25 PM

Last change on Aug 5, 2019 7:05:16 AM by Stephan Linke [Paessler Support]



1 Reply

Votes:

0

Port already in use usually means that something else is blocking that port, most of the time a different QoS Sensor. Do you have multiple of those configured, using a sequential port range (50001, 50002, etc.)? If so, increasing the port gap might be all that's required to get it working. Does an actual TCP connection on these ports work when using 50000? You could check that with either Telnet or PuTTy :)

Created on Aug 5, 2019 7:47:52 PM by Stephan Linke [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.