starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Auto Network Discovery and Ports open #5938

New Issue
Closed
opened 2025-12-29 19:34:31 +01:00 by adam · 3 comments
adam commented 2025-12-29 19:34:31 +01:00
Owner
Copy Link

Originally created by @quiknick on GitHub (Jan 13, 2022).

NetBox version

v3.1.5

Feature type

New functionality

Proposed functionality

Many other IPAM solutions have the ability to conduct Auto Network Discovery either manually or on a schedule out of the box. Please add Auto Network Discovery into the product. Yes, I looked to see if there was an issue opened for this and while there are some Network Discoveries, no one has formally requested and to the level I am requesting. Yes, I have scoured the internet looking plugins others have created. Only one plugin works that I found that uses nmap and pysnmp, but has a few quirks and does not always add devices to the interface if it can't recognize the device

It would be nice along with discovery using nmap, to also capture the ports each device/IP has open and ingest this data into IP Address, Device, and open ports.

Not Working Plugins:
https://github.com/networktocode/ntc-netbox-plugin-onboarding (Does not work on netbox 3.x)
https://pypi.org/project/np-autodiscovery/

Working with some issues:
https://github.com/marcosmamorim/netbox-device-autodiscovery

Must install nmap
sudo apt install nmap
sudo pip3 install pynetbox nmap toml lxml

Devices don't always get added. no ability to capture ports open

Use case

IPAM by itself requires manually maintaining devices and IP addresses used. Having Auto Network Discovery to find devices via IP and SNMP is very useful and can help maintain configuration management. As you may or may not know, while NetBox is the source of truth, network configurations change, and/or new devices get put on a network without proper configuration management. Then the device is on the network, but not in NetBox. There needs to be a way to identify IPs used, that are not in NetBox to either allow adding or removing.
I will be using this is to simply automate the process of importing device information, THEN I can use NetBox as a source of truth. I wouldn't use something like this every day to update documentation, but as apart of Netbox first-time setup when the environment already exists, and spot checks from time to time to vet configurations

Database changes

adding open ports functionality would require new model and fields.

External dependencies

No response

Originally created by @quiknick on GitHub (Jan 13, 2022). ### NetBox version v3.1.5 ### Feature type New functionality ### Proposed functionality Many other IPAM solutions have the ability to conduct Auto Network Discovery either manually or on a schedule out of the box. Please add Auto Network Discovery into the product. Yes, I looked to see if there was an issue opened for this and while there are some Network Discoveries, no one has formally requested and to the level I am requesting. Yes, I have scoured the internet looking plugins others have created. Only one plugin works that I found that uses nmap and pysnmp, but has a few quirks and does not always add devices to the interface if it can't recognize the device It would be nice along with discovery using nmap, to also capture the ports each device/IP has open and ingest this data into IP Address, Device, and open ports. Not Working Plugins: https://github.com/networktocode/ntc-netbox-plugin-onboarding (Does not work on netbox 3.x) https://pypi.org/project/np-autodiscovery/ Working with some issues: https://github.com/marcosmamorim/netbox-device-autodiscovery Must install nmap sudo apt install nmap sudo pip3 install pynetbox nmap toml lxml Devices don't always get added. no ability to capture ports open ### Use case IPAM by itself requires manually maintaining devices and IP addresses used. Having Auto Network Discovery to find devices via IP and SNMP is very useful and can help maintain configuration management. As you may or may not know, while NetBox is the source of truth, network configurations change, and/or new devices get put on a network without proper configuration management. Then the device is on the network, but not in NetBox. There needs to be a way to identify IPs used, that are not in NetBox to either allow adding or removing. I will be using this is to simply automate the process of importing device information, THEN I can use NetBox as a source of truth. I wouldn't use something like this every day to update documentation, but as apart of Netbox first-time setup when the environment already exists, and spot checks from time to time to vet configurations ### Database changes adding open ports functionality would require new model and fields. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:34:31 +01:00
adam closed this issue 2025-12-29 19:34:31 +01:00
adam commented 2025-12-29 19:34:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 13, 2022):

Auto-discovery has been explicitly declared as out of scope for NetBox since its inception as a network source of truth. Please see the wiki for more detail.

@jeremystretch commented on GitHub (Jan 13, 2022): Auto-discovery has been explicitly declared as out of scope for NetBox since its inception as a network source of truth. Please see [the wiki](https://github.com/netbox-community/netbox/wiki/Frequently-Asked-Questions#why-doesnt-netbox-scan-for-ips) for more detail.
adam commented 2025-12-29 19:34:31 +01:00
Author
Owner
Copy Link

@quiknick commented on GitHub (Jan 14, 2022):

I understand it is a network source of truth. And in theory I agree, but in the real world every organization I have been a part of, triage happens and configurations change. Configurations change on the fly outside of Configuration Management oversite and now you have a delta that the person or people maintaining netbox do not know about. Or you have change management windows and things change on the fly to get something done, or an additional server or device is deployed. This is very common and no matter how many policies an organization has, these things still happen.

I consider the discovery capability as a spot checking to vet what is already in the source of truth. I can guarantee I am not the lone wolf who has seen these things happen. At least consider the nmap function to see what ports are open. A very valueable set of information to know attack vectors possible on a system or set of systems and devices.

@quiknick commented on GitHub (Jan 14, 2022): I understand it is a network source of truth. And in theory I agree, but in the real world every organization I have been a part of, triage happens and configurations change. Configurations change on the fly outside of Configuration Management oversite and now you have a delta that the person or people maintaining netbox do not know about. Or you have change management windows and things change on the fly to get something done, or an additional server or device is deployed. This is very common and no matter how many policies an organization has, these things still happen. I consider the discovery capability as a spot checking to vet what is already in the source of truth. I can guarantee I am not the lone wolf who has seen these things happen. At least consider the nmap function to see what ports are open. A very valueable set of information to know attack vectors possible on a system or set of systems and devices.
adam commented 2025-12-29 19:34:32 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jan 16, 2022):

Reports are what you are looking for. You would use a report to determine if there is a delta and then action it.

A delta does not mean the change was intended, so NetBox actioning it is not desirable. Please open a discussion if you have further questions.

@DanSheps commented on GitHub (Jan 16, 2022): Reports are what you are looking for. You would use a report to determine if there is a delta and then action it. A delta does not mean the change was intended, so NetBox actioning it is not desirable. Please open a discussion if you have further questions.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5938
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?