On Thu, 18 Jul 2019 09:54:56 +0000 Martin Burman martin.burman@gu.se wrote:

We also have a lot of users directly attached to Cisco ASAs and these boxes does not give away their ARP/Neighbor cache via SNMP. The obvious first question is: has anyone successfully solved this already?

I've no idea. I've had several discussions about this with people on IRC. Several people have been trying on their own, but I've never heard back from them.

Otherwise a "sh arp/sh ipv6 neigh" gives a parseable output and I assume this is the way to go via Expect or similar:

Asa> sh ipv6 neighbor IPv6 Address Age Link-layer Addr State Interface fe80::6db1:8675:5895:8db1 423 001d.d8b7.1ce3 STALE ifname

Is there a safe way to import this kind of data to NAV? Or any documentation hints that kicks me into the appropriate direction? I assume there are logic that updates existing mac addresses and creating new ones when needed and such and I don't want to ruin our installation.

That depends on your definition of "safe" :-)

At the moment, you can insert whatever ARP record you like from the ASA into the database. However, as soon as the ipdevpoll `arp` plugin tries to collect ARP data via SNMP from the ASA and finds none, it will try to close all the open records you have inserted, since it cannot find them "any longer".

You would need some sort of switch to tell the arp plugin to not bother with the ASA at all - then you would be free do manipulate its ARP records in the NAV database as you see fit. There could be various ways to go about making such a switch. It could be per-device or per-device-type (or the arp plugin could just be hardcoded to ignore Cisco ASAs entirely).

The second idea is to run some homebrewed snmp server that runs the "sh arp" in the back end and formats the output like a L3 switch would do

To avoid complicating NAV's management code, this SNMP server would also need to proxy all other SNMP requests from NAV to the Cisco ASA.

Maybe this would be somewhat preferable as a generic solution, as it would work with any NMS, not just NAV.

if that's the suggested way to go I would appreciate a decent oneliner with snmpwalk or similar that runs against a Cisco L3 switch (6500 or 6800) so I can compare the output I need to create.

Well, the arp plugin supports fetching ARP data in four distinct ways. There are two tables in the IP-MIB: An old, deprecated IPv4-only one, and a modern IP-version agnostic one. Then there is a table in the deprecated IPV6-MIB, which some devices still support. Lastly, the ARP plugin supports a Cisco-proprietary MIB (CISCO-IETF-IP-MIB), which IIRC, is a snapshot of an IETF draft version of the modernized IP-MIB.

The most appropriate modern implementation on the agent side would be to support IP-MIB::ipNetToPhysicalTable (as described on page 66 of RFC 4293 [1]).

This oneliner would be equivalent to what NAV uses in that case:

snmpwalk -v2c -c <community> public <ipaddr> IP-MIB::ipNetToPhysicalPhysAddress

Thanks in advance and thanks a lot for a great piece of software!

Thanks yourself :)

[1] https://tools.ietf.org/html/rfc4293#page-66