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?
PING times out on an otherwise available workstation
Votes:
0
Best 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.
Votes:
0
One way ore another, the ping request is not getting through.
This can be caused by things as:
- The target computer really being down
- Hard or software firewalls blocking the ICMP request
- 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.
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.
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.
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.
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]
Add comment