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

PING times out on an otherwise available workstation

Votes:

0

At our customers site PRTG sometimes cannot ping a computer which is otherwise available and can be seen on the network for several hours. What is happening there?

falsealarms ping prtg timeout

Created on Sep 13, 2011 2:46:37 PM



Best Answer

Accepted Answer

Votes:

0

Increasing the Ping count helped in part, but the real cause was a misconfigured DNS/DHCP which scavenged stale dns-names after 7 days and the DHCP-lease-time was set to 21 days. The scavenging removed the DNS-entry for all devices which ran for weeks without rebooting and which got their IP-address via DHCP. That was hidden by Windows broadcasting name-resolution. Pings with the netbios-name and the ip-address worked, but not those with the fqdn, which is used by the sensors/probes.

Created on Sep 16, 2011 1:37:49 PM

Last change on Sep 16, 2011 4:23:22 PM by  Torsten Lindner [Paessler Support]



6 Replies

Votes:

0

Are you able to ping the host outside of PRTG? You may want to check to ensure that ICMP traffic is allowed on the hosts firewall.

Created on Sep 13, 2011 6:44:12 PM



Votes:

0

One way ore another, the ping request is not getting through.

This can be caused by things as:

  1. The target computer really being down
  2. Hard or software firewalls blocking the ICMP request
  3. Routers (of your internet provider) dropping ICMP trafic when their load reaches a centain limit.

If, like you say, it only happens sometimes and the ping travels from your PRTG server to the target computer over the internet, I would bet on the 3rd option.

Created on Sep 13, 2011 6:47:21 PM



Votes:

0

The ping travels (or does not travel) from our customers PRTG server to the target computer on site, so only intranet-connections inside of the same subnet. If the target computer is pinged directly from the command-line of the server, we get an answer during the times, where PRTG does not get one.

Created on Sep 14, 2011 8:25:48 AM



Votes:

0

There's only a firewall to the outer intranet (and to the internet, of course) but all involved computers are inside an inner intranet where no firewalls, be it software or hardware, are acitvated/installed. The PRTG-server and other monitored servers have connections to several networks but the targets in question are are all inside one dedicated client-network and have only that network-connection. None of the servers had this problem, yet.

Created on Sep 14, 2011 8:47:33 AM



Votes:

1

You can also increase the Ping Count on the ping sensors that show this 'problem', then one single lost ping packet will not cause the sensor to go into error state anymore.

Created on Sep 14, 2011 12:28:42 PM by  Torsten Lindner [Paessler Support]



Accepted Answer

Votes:

0

Increasing the Ping count helped in part, but the real cause was a misconfigured DNS/DHCP which scavenged stale dns-names after 7 days and the DHCP-lease-time was set to 21 days. The scavenging removed the DNS-entry for all devices which ran for weeks without rebooting and which got their IP-address via DHCP. That was hidden by Windows broadcasting name-resolution. Pings with the netbios-name and the ip-address worked, but not those with the fqdn, which is used by the sensors/probes.

Created on Sep 16, 2011 1:37:49 PM

Last change on Sep 16, 2011 4:23:22 PM by  Torsten Lindner [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.