FR - API Endpoints to submit arpnip and macsuck results

[rc9000]

It would be great if we could submit arpnip and macsuck results via API. Usecases:

• results from devices with poor SNMP support but other means to read arp and mac address tables (e.g Palo Alto in App::Netdisco::SSHCollector::Platform::PaloAlto broken ? #755)
• results from devices with broken VLAN indexing (e.g. Cisco IOS 17 in Non-CDP discovered 'Connected devices' (nodes) not being found/displayed on Cisco Catalyst 9300/9500. Macsuck/walk issue it seems #883)
• importing flat files because people don't trust me with SSH on their equipment :)

I think this could open up new classes of devices with significantly lower barrier to entry than we had with e.g. the Worker Plugin-based SSH collector.

[ollyg]

had "a big think" all about arp/mac submission API endpoints. Like all things, more tricky than it first seems, but I believe I have a way forward. I'll need to refactor the existing arp/mac code a bit then can work on the API

the tricky bit is that Netdisco is doing a lot of sanity checking and cleanup of the data it gets from the device, for example to filter VLANs, and most important to make sure that nodes appear on the switch they are on (basically discarding remote nodes, but it's more complex than that). I'd like to keep all this logic so that you just submit the MAC table and don't worry about uplinks/etc and Netdisco still applies all its filtering

plus taking into account all the config options we have, like allowing "bleed" to upstream switches, ignoring specific VLANs or Ports, etc

basically ... not safe just to dump a mac/arp table into the database, it'd screw up the secret-sauce of netdisco

[maxslug]

On 11/2/22 07:51, Oliver Gorwits wrote: basically ... not safe just to dump a mac/arp table into the database, it'd screw up the secret-sauce of netdisco

Ollie, Don't give away all our secrets!

…

-m

Message ID: ***@***.***>

[ollyg]

Ollie, Don't give away all our secrets!

Netdisco is written in Perl. We're safe.

[rc9000]

Excellent many thanks!

No ETA, but I plan to extend ntcsuck to support all main Cisco OS variants and make it a viable option for snmpv3-only networks with many switches and vlans. We'll see how that goes :)