Network Discovery – Automatically Incorporating New Subnets into Discovery Scope

SteveR781314613
Tera Contributor

Monday

Hi all,

We’re currently implementing Network Discovery within ITOM and are trying to better understand how it handles newly discovered subnets in dynamic network environments.

Use Case

Our environment frequently introduces new subnets, and we’re aiming to minimize manual effort in maintaining Discovery scope. Ideally, we’d like Discovery to adapt automatically as the network evolves.

Specifically, we’re trying to:

  • Automatically include newly discovered subnets in Discovery
  • Organize those subnets into Discovery Range Sets (e.g., by location)
  • Avoid ongoing manual creation and maintenance of IP ranges

What We’re Seeing

From testing so far:

  • The Auto Discovery Subnets related list is being populated over time as Discovery runs
  • These subnets include useful metadata like location and associated network devices
  • However, they do not appear to automatically translate into Discovery IP Ranges or populate Range Sets
  • Discovery Range Sets and IP Ranges still need to be created and maintained manually

We’re also trying to better understand the role of the Auto Discovery Subnets list:

  • Does it represent all subnets discovered during a schedule run?
  • What determines which subnets are included?
  • Is there any intended connection between these subnets and the actual Discovery scan scope?

Gap / Challenge

We initially expected Network Discovery to dynamically expand its scope based on discovered topology.

Instead, it seems:

  • Auto-discovered subnets are informational only
  • Discovery scope must still be explicitly defined (IP ranges / range sets)
  • There’s no out-of-the-box way to convert discovered subnets into active Discovery ranges

This creates a scalability concern in environments where subnets change frequently.

Questions for the Community

  1. Is there any out-of-the-box functionality to convert Auto Discovery Subnets into Discovery IP Ranges or Range Sets?
  2. How are others handling dynamic environments where new subnets are introduced regularly?
  3. Is there a recommended approach for keeping Discovery scope updated without heavy manual effort?
  4. Can Range Sets be automatically populated based on attributes like location?
  5. Are there best practices (e.g., leveraging IP Network CIs or other data) to support this kind of automation?

Goal

We’re looking for a scalable and supported approach where:

  • Newly discovered subnets can be incorporated into Discovery scope automatically
  • Range Sets can remain logically organized
  • Manual maintenance is minimized

If this isn’t supported out of the box, any guidance on recommended patterns or architectures would be greatly appreciated.

Thanks in advance!

0 Helpfuls
  • 145 Views
1 REPLY 1

ayushraj7012933
Mega Guru

yesterday

Hi @SteveR781314613 ,

This is a very common challenge in dynamic environments, and the approach you’re thinking about is absolutely the right direction. Instead of relying on manual updates, you can automate the conversion of discovered subnets into usable Discovery ranges in a controlled way.

Here’s a practical, field-tested way to implement it:

Step 1: Use Auto Discovery Subnets as Source

Start with the Auto Discovery Subnets table (typically discovery_subnet depending on version).

Focus on:

  • Subnet (CIDR)

  • Location

  • Discovered by

This becomes your source of truth for new subnets.

Step 2: Prevent Duplicate Processing

Add a custom field like:

  • u_processed (True/False)

This ensures each subnet is handled only once and avoids duplicate IP ranges.

Step 3: Automate Using Flow Designer

Create a Scheduled Flow:

  • Run frequency: every few hours or daily

  • Condition: u_processed = false

This keeps the process lightweight and automated.

Step 4: Add Validation (Very Important)

Before creating any IP range, validate:

  • Subnet is internal (10.x / 172.x / 192.168.x)

  • Location is populated

  • Subnet does not already exist in Discovery IP Ranges

You can handle this via:

  • Flow conditions (basic)

  • Script step (recommended for flexibility)

Step 5: Create Discovery IP Range

In the flow:

  • Create record in discovery_ip_range

  • Map:

    • Name → Subnet (e.g., 10.10.10.0/24)

    • Start IP / End IP → derived from CIDR

You’ll likely need a small script step to convert CIDR into start/end IP.

Step 6: Dynamically Assign to Range Sets

Use location-based logic, for example:

  • Mumbai → Mumbai Range Set

  • Bangalore → Bangalore Range Set

Then relate the created IP range to the correct Discovery Range Set.

Tip: Keep naming conventions consistent for easy mapping.

Step 7: Mark as Processed

Once everything is successful:

  • Set u_processed = true

Step 8: Logging & Error Handling

Don’t skip this part:

  • Log invalid subnets or missing data

  • Optionally notify admins for failures

This helps in long-term maintenance.

0 Helpfuls