ICMP-based discovery with manual parent-child device linking

[bibisheksteephengs-svg]

Is your feature request related to a problem? Please describe.
OneUptime currently supports SNMP-based Discovery Scans to find devices and build Network Topology links. However, many devices on our network don't support/respond to SNMP and can only be discovered via ICMP (ping). There's currently no ICMP-based discovery scan type, so these devices aren't discovered automatically. Additionally, when automatic topology link discovery fails (no SNMP/LLDP/CDP data to determine relationships), there's no way to manually define how a discovered device fits into the topology.

Describe the solution you'd like

• Add an ICMP Discovery Scan type, alongside the existing SNMP Discovery Scan, to find devices that only respond to ping.
• Add a manual "Link Device" option in Network Topology / Devices, so that when auto-discovery can't determine the parent-child relationship, a user can manually assign one device as the parent of another (e.g., Router → parent; Switch → child of Router; Access Point → child of Switch, i.e. grandchild of Router).
• Allow ICMP-discovered devices to be manually linked as children under existing SNMP-discovered devices (e.g., linking an ICMP-only device as a child of the Switch it's physically connected to), so the full topology tree is complete even where auto-discovery has gaps.

Describe alternatives you've considered
Manually tracking ICMP-only devices and their network position outside of OneUptime, since they don't appear in Topology at all currently.

Additional context
This is related to two other filed requests: "Network Topology should include manually-added Ping-monitored devices, linked via labels" and the incorrect-link bug reported separately for SNMP-discovered devices ("Unmanaged neighbor" links). Together, these would let Topology represent the full network — SNMP-discovered, ICMP-discovered, and manually-added devices — with correct parent-child structure even where automatic discovery can't determine it.

[simlarsen]

Thanks for filing this — and for the detail, it made the three requests easy to separate.

First, some of this may already be solved for you. #3023 was closed the day before you filed this, and the work that closed it is on release. If you are on a build from before 13 August you would not have seen any of it. That release already added:

• Ping-only devices are importable. A discovery scan already sweeps ICMP before it tries SNMP, and hosts that answer ping but not SNMP now import as monitor-backed devices — no probe, no credentials, health supplied by a Ping or IP monitor you bind to them. Previously they were refused outright, which is why they were absent from Topology entirely.
• Manual device links. Network > Device Links lets you draw a cable between two devices that LLDP and CDP cannot see. It is merged into the same edge as a discovered link between the same pair, so you never get two lines for one cable.
• Label-driven uplinks. Network > Settings > Link Rules draws links from labels, stated as child labels and parent labels.
• The "unmanaged neighbour" links you screenshotted turned out to be a matching bug, not display noise — devices were only indexed by name, so a peer advertising an HP/Aruba serial as its LLDP chassis id could never match a device we already managed. That is fixed, along with a way to hide nodes that should not be on the map at all.

Worth checking that against your estate before anything else.

What was still missing, and what we have just added

Two real gaps remained, and they are the ones that actually decide whether your topology comes out right. Both are now on master in #3217.

1. You could draw a link but not say which end was the parent. The link already stored a direction, and the map threw it away — the Parent-Child view re-derived the hierarchy from scratch using device roles and connection counts. A link now has an optional Parent Device field. Set it and the Parent-Child view draws the other end beneath it; leave it empty and nothing changes from today. Link rules already know which end is the parent (that is what the child/parent labels mean), so those now declare it automatically.

2. A ping-only device had no role, and that put it at the top of the map. Device roles were classified purely from SNMP identity — sysDescr, sysObjectId, model. A device nothing walks has none of that, so it was permanently "unknown", and any managed device with no role was ranked at core level, alongside your routers. An access point imported by ping could therefore be drawn above the switch it hangs off, and could even win the root of the tree. Devices now have an optional Device Role you can set yourself. It beats the classifier where it is set, and the tiering reads it: routers, firewalls and load balancers sit at core level, everything else one below.

Together those two mean your example works end to end — Router as parent, Switch beneath it, access point beneath the Switch, whether or not any of them speak SNMP.

What we have not done

The ICMP-only scan type. We deliberately deferred it. A discovery scan today still requires SNMP credentials on the form even though the sweep already pings first and already reports what answered — so you can find and import your ping-only devices right now, you just have to give it some SNMP credentials to get there. A scan type that skips SNMP entirely is worth adding for operators who have no credentials at all, and we will pick it up separately; it was simply the least valuable of the three, and shipping it before the other two would have handed you a pile of role-less devices sitting in the router tier.

If you try the current release and something in the first list is still not behaving, please say so — that part should already work, and if it does not we would rather know before building on top of it.

[bibisheksteephengs-svg]

Thanks for the detailed update — really appreciate the breakdown of what shipped vs. what's still deferred.

Tried this against our estate on a build after 13 August (confirms #3217 is present — Device Links and Link Rules are both working, and per-unit Parent-Child linking now works correctly, router → switch → AP, exactly as described). Confirmed on WB Unit 0661 (screenshot attached: Tiered view showing UN0661WANRTR01 correctly as root, three switches beneath it, APs beneath those).

Ran into one new issue with ICMP-only device import though, wanted to flag it here since it's directly related:

ICMP-discovered devices are stuck in "Pending" status with no hostname, even though they respond to ping.

• Devices imported via a Discovery Scan that only answer ICMP (not SNMP) show:
  • Status: Pending (never transitions to Up/Down)
  • Name/Hostname: just the raw IP address (e.g. 10.114.167.12), no resolved hostname — even for devices that do have a hostname reported elsewhere (e.g. UN0660KDS01, UN0661KPS01 show a name, but most show only the IP)
  • Device Overview page confirms: "Never polled", 0/0 interfaces, "No interfaces discovered yet. Interfaces appear after the first successful SNMP poll." — makes sense for a ping-only device (no SNMP to poll), but Reachability still shows "Pending" rather than reflecting actual ping-based health
• Confirmed via manual ping these hosts are online and responding

Given the release notes above mention "health supplied by a Ping or IP monitor you bind to them" — is manually binding a Ping monitor to each device the expected/required step to move it out of "Pending", or should Reachability reflect ping status automatically post-import without a bound monitor? If a monitor bind is required, might be worth a callout in the scan results / device list so it's clear these devices need that extra step, since right now they look identical to a broken/misconfigured device.

Screenshots attached: device list showing multiple Pending ICMP-only devices with IP-only names, and one device's Overview page showing the "Never polled" / "No interfaces discovered" state.