When configuring a discovery rule that scans a specific subnet and uses SNMPv2 checks with the following parameters:

• Checks:
  • SNMPv2 agent 1.3.6.1.2.1.1.1.0
  • SNMPv2 agent 1.3.6.1.2.1.1.5.0
• Device uniqueness criteria:
  • SNMPv2 agent 1.3.6.1.2.1.1.5.0
• Hostname and visible name:
  • SNMPv2 agent 1.3.6.1.2.1.1.5.0

Despite this configuration, the discovery process adds the same device (same SNMP name) twice, under two different IP addresses (e.g., x.x.x.1 and x.x.x.2).

The expectation is that Zabbix would identify these as the same device - based on the defined “Device uniqueness criteria” - and would not create multiple hosts with identical SNMP system names.

Example Use Case:

Within an environment, a network discovery is performed across multiple subnets per city:

• 201.200.50.xx → Bangkok
• 201.200.51.xx → Cardiff
• 201.200.52.xx → Denver

Each discovery rule is configured to assign tags and host groups based on the subnet (city).
Some network devices (e.g., router1) have multiple management or out-of-band IPs across different subnets.
Currently, when these are discovered, Zabbix creates multiple hosts - router1, router1_2, router1_3, etc.

Expected Behavior

• When a new discovery rule detects a device whose uniqueness criteria value (for example, SNMP sysName or sysObjectID) already exists in the system,
  the server should not create a new host, but rather:
  • Trigger the discovery action logic (e.g., assign/update tags, update groups)
  • Optionally update host interfaces or merge new IPs into the existing host (configurable)
  • Skip creating an additional host object

Why This Matters

• In large environments with thousands of network devices, especially OOB routers and management interfaces, it’s impossible to know all IPs in advance.
• Overlapping discovery ranges are unavoidable, and duplicate hosts cause incorrect alerts, duplicate triggers, and unnecessary database load.
• Allowing Zabbix to respect the Device uniqueness criteria globally across rules will make network discovery scalable and logical.

This feature would align host creation with real-world SNMP identity rather than IP-based logic, while still preserving the current tagging/grouping workflow per rule.