Skip to content
← Auto-Discovery and Network Topology

How can we improve automated or manual device discovery?

Auto-Discovery and Network Topology

Categories

Supported Interface Filtering for SNMP Auto-Discovery Templates

As a Network Engineer managing hundreds of Cisco switches and routers,
I want to define supported, documented interface filters (by name, operational status, speed, and type) within SNMP Object Discovery Templates,
so that auto-discovery only creates SNMP Traffic sensors on the interfaces I actually need to monitor — eliminating manual post-cleanup and unsupported XML hacks.

Problem: When using ODTs to auto-discover SNMP Traffic sensors on Cisco switches and routers, PRTG creates sensors on all interfaces — including loopbacks, VLANs, tunnels, and inactive ports — with no officially supported way to filter them at discovery time. The <include> filter in device templates is undocumented, unreliable, and explicitly unsupported.

Requested capability:
Add a supported, documented interface filter inside SNMP Object Discovery Templates with the following filter fields and operators:

Interface name

Wildcard / substring match (e.g. Cato)

Interface status

Operational status = Up only

Interface speed

Speed > 0 or ≥ defined threshold (bps)

Interface type

Exclude loopback, VLAN, tunnel, virtual

Business impact:
Without this, enterprise deployments across hundreds of Cisco devices (with inconsistent interface aliases and non-uniform indexes) are forced into one of three poor outcomes:

Manual post-discovery cleanup — high effort, does not scale
Unsupported XML template hacks — unreliable across PRTG versions
No auto-discovery at all — defeats the purpose of ODTs

Expected behaviour:
<include>
(
name = Cato AND
status = up AND
speed >= 1000000 AND
type != softwareLoopback AND
type != propVirtual
)
</include>

This syntax (or an equivalent GUI-based filter builder) should be officially supported and documented, with clearly published field names, operators, and known limitations.

19 votes

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Paramesh SV shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded  · 

Hi everyone,

Thank you all for voting on this idea.

Before we can commit to developing this idea, we need more input from the community.

We want to clarify: filtering/controlling which interfaces are monitored by the SNMP Traffic sensor during Auto-Discovery has actually been possible in PRTG for quite some time, by editing the ODT file: https://helpdesk.paessler.com/en/support/solutions/articles/76000041645-how-can-i-include-and-exclude-sensors-from-device-templates-

Since version PRTG .118, it has also been feasible with the SNMP Traffic v2 sensors.

That said, we understand that manually editing ODT files is not the most intuitive experience, and we suspect that's exactly the pain point many of you are hitting.

To help us prioritize the right improvements, we'd love to hear from you:

  • What is your specific use case? (e.g., filtering by interface name, speed, type, etc.)
  • What makes the current ODT-based approach difficult or impractical for you?
  • Would a graphical UI for managing these filters solve your problem?

Thanks again for helping us make PRTG better!


Best regards,

The Paessler Product Team

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Joshua Moore commented  ·   ·  Report

    Hi, I just want to point out that article you listed explicitly calls out:

    Important: The behavior of the SNMP Traffic sensor is different. For details, see How does auto-discovery with SNMP Traffic sensors work?

    Then on this page:
    https://helpdesk.paessler.com/en/support/solutions/articles/76000063335-how-does-auto-discovery-with-snmp-traffic-sensors-work

    It states:

    The auto-discovery always creates SNMP Traffic sensors for all interfaces whose SNMP traffic counters are above 0. As a result, every interface that has had traffic since the last restart of the monitored device is added, even if it is currently disconnected or disabled.

    This leads us to believe that filtering logic does not work with SNMP Traffic sensors. The documentation conflicts with this feature request. Can you confirm?

  • Kevin Farley commented  ·   ·  Report

    This feature would be greatly helpful to be able to specify the monitored interfaces and streamline our workflow. Thank you!

  • Justin Vickery commented  ·   ·  Report

    This would indeed be very helpful for our workflow.

  • Adam Schaeffer commented  ·   ·  Report

    This would be very helpful for our organization as well! This is a meaningful limitation for our PRTG use cases.

  • Joshua Moore commented  ·   ·  Report

    As a PRTG admin, I need to be able to control what types of SNMP Traffic sensors are auto-discovered. We should be able to templatize the SNMP Traffic criteria based on ifAdminStatus, ifOperStatus, ifSpeed, ifType, etc.

    As things are today, if a device has thousands of virtual interfaces and only dozens of physical interfaces, and all I care about monitoring are physical interfaces, there's no way to have auto-discovery only discover and add physical interfaces. Other NMSes allow the admin to filter on ifType for this functionality. Same thing if we want to layer on business logic like "only enabled interfaces" which would be for a particular ifAdminStatus. Same for "only 10G interfaces" which would be ifSpeed...

    The use cases go on and on for how helpful this can be with decluttering PRTG and improving performance.