Zabbix discovering "phantom" hosts

[Clontarf[X]]

I have a strange one, Zabbix keeps discovering hosts that no longer exist on the network.

For example, I have a switch that was removed over a year ago, Zabbix keeps re-detecting it as an ICMP host, then tries to add it with both SNMP and ICMP checks.

The device definitely does not exist and definitely does not respond to ICMP or SNMP as per the checks.

Could it be a bug with the conditions looking for "Discovered" and "Up"? Some kind of weird database/discoverer bug?

[tim.mooney]

Your Action condition A says "10.26.46.0/24" not "10.26.48.0/24". Could it be related to that?

Also, why is your action using (B or C) for conditions? I'm confused why you would want to do that. I would think that those two conditions, when ORed, would always be true once a box has been discovered once.

[Clontarf[X]]

Thanks Tim, I have the "or" condition because I don't fully understand the impacts of those two conditions (I also can't find it documented). In any case I have removed them now, so we'll see if that helps.

The IP address given is just an example, so not part of this issue.

Cheers

[Clontarf[X]]

Hi friends,

I've got this happening again at another Zabbix installation. Any ideas?

"10.30.25.33" is an old SNMP/ICMP device that was discovered by Zabbix. It has since had it's IP changed and Zabbix has now detected the new IP correctly.

However if I delete "10.30.25.33" (because I no longer want Zabbix to monitor a device that doesn't exist), it gets re-discovered by Zabbix.

Why is Zabbix thinking this device is online and responding at the time of discovery? It definitely isn't.

Status of discovery shows that these devices haven't been "discovered" in over 1 month, but if I were to delete this host, it'd re-appear after my discovery interval (12 hours).


PING 10.30.25.33 (10.30.25.33) 56(84) bytes of data.
--- 10.30.25.33 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9224ms

# snmpwalk -v2c -cpublic 10.30.25.33
Timeout: No Response from 10.30.25.33


This is occurring for hundreds of hosts that have had their IP address changed. I have a theory that it's a remote arp cache, but I was hoping someone could confirm this for me.

Cheers

[theheavy]

Heya,

I also stumbled over this behaviour and did some database research because I couldn't find anything Discovery Job related. Hosts have been poppin up even after disabling the discovery for some weeks. So this lead mit to the database.

Since I did not found any connection between the tables dhosts and hosts I gave it a try, did a backup and deleted every row in "dhosts" since then - no more phantoms.

Maybe(!) it's just a broken code line checking for the "status up" (database dhosts.status value '1').

The table dhosts will fill up with the current number of hosts again, all dhosts.status = '0', creating new dhosts.dhostid values from 1 and counting.

I did not recognize any troubles so far.

[jmedlock]

I've been battling this for a while also. I truncated the dhosts and dservices database table and let it repopulate with the new hosts. I've only done this in my dev environment, however, roughly 20 hosts have been readded to the dhosts and dservices tables. Not a super big return, but I haven't gotten any `phantom` devices readded.

I'll add the source that assisted me with truncating those tables, since when you try to do it MySQL (mariadb) complains about the Foreign Key. But all you have to do is:

SET FOREIGN_KEY_CHECKS = 0;
TRUNCATE table $table_name;
SET FOREIGN_KEY_CHECKS = 1;

Source: https://www.edureka.co/community/815...int-references