I'd consider this feature as most critical if we will concern the "uniqueness" limitations, so I'm linking in this comment related issues.

A bit related issue - ZBXNEXT-1495
Related issue ZBXNEXT-213

Some technical details available here: http://www.zabbix.com/documentation/2.0/manual/config/notifications/action/operation/other

I've performed several experiments with and without proxies (all are ~2.0.4rc1).
I used two discovery rules (1st(id=10) - zabbix agent check "system.uname", 2nd(id=11) - snmp check "SNMPv2-MIB::sysName.0") with identical short IP range.

In each discovery rule I used NOT IP address uniqueness criteria but different ones - zabbix and snmp respectively.
Returned values for particular host were different for agent and snmp checks.

Without proxies the result I've received was as expected:
snmp interfaces have been added to existing hosts (already with zabbix agent interfaces)
It's actually described in documentation bottom of a page http://www.zabbix.com/documentation/2.0/manual/discovery/network_discovery.
There hard to complain for zabbix server because a server executing it has single routing table.
But ... there still could be an option to control this - create new host or add new interface.

But WITH proxies received results were as not intuitively expected.
I had hosts (with zabbix interfaces) created by 1st drule DISCOVERED by a 1st proxy,
then I disabled 1st drule and enabled 2nd drule performed on another 2nd proxy.

IPs from 2nd proxy have been added as snmp-interfaces to hosts previously created by 1st discovery from 1st proxy.

We know that zabbix server is responsible to process results of network discovery from proxies.
But in this case I would expect that zabbix server will take care that results of discovery returned from ANOTHER 2nd proxy.

So zabbix anyhow is not ready to perform discovery of identical IP ranges.

I don't suppose there's any way to extend this to cover situations where you may want two proxies to monitor the same device for redundancy purposes. While the redundancy aspect may not be a current feature, designing the uniqueness to account for this would be good architecturally. Perhaps have some form of metadata attached to the proxy that would define whether the devices are in fact on the same IP network or not. In the use-case of an IT service provider monitoring clients, the metadata would clearly be the customer name or ID.

I'm just mentioning this as it seems that this feature is currently under development so it would be a shame not to mention it now. If it requires more funding I would consider helping on this front.

No, this feature is not under development currently (status=open).

I wanted to add some technical details.
In a function "add_discovered_host" (operations.c#190) for both (network discovery and autoregistration) events server will update "monitored by proxy" host field:

else
			{
				if (host_proxy_hostid != proxy_hostid)
				{
					DBexecute("update hosts"
							" set proxy_hostid=%s"
							" where hostid=" ZBX_FS_UI64,
							DBsql_id_ins(proxy_hostid), hostid);
				}

				DBadd_interface(hostid, interface_type, 1, row[2], row[3], port);
			}

if discovered|autoregistered host by|from another proxy and the host already exists.

Screenshots of my configuration causing the issue

According to http://www.zabbix.com/development_services.php this is under development. Is that not correct?

hmm, god catch Adrian
I didn't know about that.

I'm not sure is it indeed under development at the moment.

Any update on the development progress of this feature? This is a showstopper for us fully implementing Zabbix.

I see that Andris Zeila was assigned to this task.

Hello Andris! Does this mean that you are working on this feature?

How far along is the development? We are eagerly awaiting this feature as this is a showstopper for our Zabbix implementation.

Hi Andris - just want to say pretty much the same as what Michael has said. Obviously I can read that the details on this issue do not have a "Fix Version" set but do you know at this early stage if this is likely to end up in 2.2 or are we probably going to have to wait for 2.2.1 or even 2.4?

Hi, I just started to work on it and yes, it should be done for 2.2

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1267

(1) let's have a spec on .org

wiper as it was decided to nod create an option for this the changes are quite trivial. I don't think we need to write a spec on such changes.

<richlv> as could be seen by other changes, we do - but i guess it's too late for this one, CLOSED

I just discussed it with sasha. We decided to implement it as initially suggested, i.e. hosts discovered by different proxies are considered to be different. There will be no options to control it.

Note that current implementation allows several physical hosts (having same IP) to be treated as a single one in Zabbix, it should not be allowed by design.

In that case I'm setting it as resolved - the current fix (r38521) covers the initial suggestion (considering hosts discovered by different proxies to be different).

Andris,

Does this feature depend on anything in 2.2? Or will we be able to backport it to 2.0?

Untested backport of ZBXNEXT-1267 to 2.0.8

If there were no real problems in backporting this patch (missing fields or something like), then it should work. At least I can't think about any dependencies offhand.

Successfully tested!

Please review my changes in r38620.

Updated documentation, please review:

• https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew220#network_discovery_changes
• https://www.zabbix.com/documentation/2.2/manual/discovery/network_discovery/rule#changing_proxy_setting

sasha CLOSED

I've been running on 2.0.8 using the backported patch with no issues - much better, thanks!

Thank you for all this work - you've made me very happy. Just one last question - when is it likely that we'll see this in a full release. Do you think we'll see it first as 2.0.9 or as 2.2 and are there any projected dates, even vague? I'm really not comfortable patching 2.0.8 or running pre-release 2.2 code.

Available in version pre-2.1.5 (trunk) r38622.

this seems to work incorrectly with uniqueness criteria other than ip - see ZBX-7744