New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


PING times out on an otherwise available workstation

Votes:

0

Your Vote:

Up

Down

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 by  Lars Corzilius (50) 2 1



Best Answer

Accepted Answer

Votes:

0

Your Vote:

Up

Down

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 by  Lars Corzilius (50) 2 1

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



6 Replies

Votes:

0

Your Vote:

Up

Down

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 by  Drew Heath (0) 1



Votes:

0

Your Vote:

Up

Down

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 by  PRTG Tools Family [prtgtoolsfamily.com] (12,835) 3 4



Votes:

0

Your Vote:

Up

Down

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 by  Lars Corzilius (50) 2 1



Votes:

0

Your Vote:

Up

Down

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 by  Lars Corzilius (50) 2 1



Votes:

1

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  Lars Corzilius (50) 2 1

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



Please log in or register to enter your reply.


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.