Network autodiscovery and topology

[mksoska]

Hello everyone,

I want to add a new functionality - network autodiscovery and topology - to the NetBox. It is the topic of my bachelor thesis. I found this existing plugin https://github.com/lopes/netbox-scanner, that discovers hosts on L3 (with Nmap or NetXMS) and adds them to the NetBox configuration.

The thing is, I need to scan L2 topology of my network, and then process this information in NetBox.
I'd like to ask if you've got any suggestions of how to deal with this problem, or any advice about tool/plugin you would use. There some open-source network scanners (that can operate on L2) available, but how to efficiently connect the scan results with NetBox? Would I have to code this plugin myself?

Thank you for any ideas.

[candlerb]

Regarding your specific question about how to detect L2 topology: this is normally done by querying devices for LLDP or CDP neighbor information (normally over SNMP, although for some devices you may have to use a CLI to do this). However, for this to work, LLDP needs to be active on both devices at each end of the link, and although most switches and routers support this, most edge devices (clients and servers) don't. In that case, you can instead try to infer topology from bridge forwarding tables and/or spanning tree topology. There is an old and mostly unmaintained project called Netdot which does that; you could steal some ideas from here.

As to the more general issue: auto-populating goes against the Netbox philosophy, as described here: https://netbox.readthedocs.io/en/stable/#serve-as-a-source-of-truth

NetBox intends to represent the desired state of a network versus its operational state. As such, automated import of live network state is strongly discouraged. All data created in NetBox should first be vetted by a human to ensure its integrity. NetBox can then be used to populate monitoring and provisioning systems with a high degree of confidence.

What I'd suggest instead is the following.

• Create a database of data collected from various sources: ARP caches, LLDP neighbours, bridge forwarding tables, SNMP interfaces etc. Maybe you can use an existing scanner as you already described. (Netdisco I believe is one, but I haven't used it)
• Compare, where possible, the data collected against the data in Netbox
• Highlight any inconsistencies: e.g.
  • A device is seen on IP address x.x.x.x, but Netbox has no record of that address
  • LLDP detects a link from device X interface A to device Y interface B, where Netbox thinks device X interface A is unconnected, or is connected to some other device
  • a port is detected as active (operational status is Up), but Netbox says nothing is connected to it
  • device X has serial number AAA in Netbox, but SNMP says its serial number is BBB
  • ... this list can grow over time
• Allow the user to resolve this in one of two ways:
  • They can go into Netbox to make the data consistent
  • They can mark the inconsistency as acceptable. (This fact needs to be persisted in the scanner database so that future scans don't keep flagging the same problem, and then purged when it no longer applies)

Note: in general it's not possible in general to automatically resolve these inconsistencies. For example, suppose the scanner detects a connection between interface A and interface B. It's not sufficient to automatically create a cable between these two interfaces; it could be that the cable goes via patch panels, and LLDP can't tell you the cable routing.

More generally: if a new IP address is detected, the scanner can't even tell whether it's a Device or a Virtual Machine! (Netbox's data model does not support converting an entity between Device and Virtual Machine, so if you get it wrong, you have to delete it and start again). So if it's going to offer to auto-create an entity, it would need to ask for some human guidance first. If it's very clever, it could use topology information to see if the detected address is present on any switch ports which belong to a device which is a member of a VM cluster, and then guess that this is a VM. But in each case it's proposing a change to Netbox which needs to be checked and confirmed by a human, before being applied.

There are some cases where click-to-resolve button would be useful: e.g. if Netbox already knows about a device, and SNMP detects a number of interfaces which Netbox doesn't know about. In that case, it would be reasonable to have a button to push interface creation through to Netbox (although you might also want to ignore some interfaces - e.g. some Dell switches show hundreds of non-existent interfaces in SNMP)

Another note: inconsistencies of omission may be detected but be not problematic. For example, Netbox may show a cable between interface A and interface B, but LLDP doesn't detect this connection. That could be because one of the devices doesn't support LLDP. Or it could be because one of the devices is currently powered off or rebooting. Or it could be because the cable is in "planned" state and hasn't been installed yet. Hence again it should be possible to accept such inconsistencies.

Suppose Netbox says a device has a given interface, but it's not in the list of interfaces returned by SNMP. It could be that the interface has been removed, but it could simply be that the interface has a different name. You wouldn't automatic resolution which deletes the interface from Netbox without confirmation.

Some detected information probably doesn't want to be imported into Netbox anyway. For example, every time an unmanaged client device picks up an IP address via DHCP, you probably don't want to record that device in Netbox. The fact that the IP address is marked "DHCP" in Netbox is good enough.

Therefore, I think the scanner database should have its own web interface. Being able to do an instant query such as "show me what port the machine with IP address 1.2.3.4 is active on" can be very helpful for locating a client device, even if you don't plan to add it as a device in Netbox. (Note: I think there's a Netbox feature request in github for being able to mark as switch port as "in use" without actually connecting it to a cable, but it hasn't been done yet)

Good luck!

[mksoska]

Thank you very much for fast reaction. Very informative! This plan seems promising. I thought of an L2-autodiscovery-and-topology use case, that wouldn't brake Netbox Source-of-Truth principle and it is pretty much the same as you described. Compare L2 scan with the Netbox configuration and highlight reasonable inconsistencies. Now, seems even more real for me with your detailed specification. I want to take an iterative approach, I mean adding features like the button for new host addition may be a future extension for the project, so I will start just with topology comparison (probably even this standalone feature will take a huge amount of time). As @xkilian wrote, phasing the project. Will see how far I'll get. I bet coding the plugin for this will be a time demanding study and work. The standalone scanner is definitely a way to go, though I'm still not sure about technical implementation of the Netbox part, this will need a further research (at least of the Netbox API). So again, thank you very much for showing the right direction.

[xkilian]

Actually when writing a plugin, you are not using the API, your are using the python abstraction directly, even easier. There are great webinars that were created by the NetworkToCode guys that gives a nice intro to the various ways of interacting with Netbox including writing plugins. See Custom Scripts and Plugins presentation.

[mksoska]

Oh, great to know, thanks! Will explore it.

[xkilian]

Very well described. I would also highlight that identifying such anomalies can also server for security related endeavours, so outputing devices devtected states could also be sent to a logging output to be correlated in Security/Logging system like Splunk/LogRhythm/Qradar.
@mareksoska22 Select a scope for your projet that can be delivered in phases, where each phase should provide tangible value. You cannot deliver everything, so choose wisely what can be done in your time frame.