Support fetching ARP entries from all Arista VRF instances

[indy-independence]

Is your feature request related to a problem? Please describe.
When using Machine tracker -> IP search or searching for an IP prefix only addresses from the global routing table (VRF) shows up. This is a problem because all our clients are routed inside VRFs, so we will not find any client devices at all.

Describe the solution you'd like
I would like ARP entries from VRFs to be detected and scanned by NAV.
I have found this MIB to query what VRFs are available on an Arista device:
https://www.arista.com/assets/data/docs/MIBS/ARISTA-VRF-MIB.txt

Using "community indexing" you could query the same OIDs for ARP table but in each VRF like this (similar to Cisco):
https://eos.arista.com/forum/vrf-snmp/

Describe alternatives you've considered
I have considered if maybe it's possible to disable/hide IP search if it's not possible to fix this since it can be confusing for users to have a search that will never display any results

Additional context
We have a lab with Arista switches where you can test this out, some sample outputs:

d1# show snmp mib walk ARISTA-VRF-MIB::aristaVrfRoutingStatus
ARISTA-VRF-MIB::aristaVrfRoutingStatus[STRING: IOT] = BITS: C0 ipv4(0) ipv6(1)
ARISTA-VRF-MIB::aristaVrfRoutingStatus[STRING: MGMT] = BITS: C0 ipv4(0) ipv6(1)
ARISTA-VRF-MIB::aristaVrfRoutingStatus[STRING: STUDENT] = BITS: C0 ipv4(0) ipv6(1)

$ snmpwalk -v2c -c <community>@MGMT <ip> iso.3.6.1.2.1.4.22.1.2
iso.3.6.1.2.1.4.22.1.2.2000001.192.168.0.101 = Hex-STRING: FC BD 67 83 A5 93
iso.3.6.1.2.1.4.22.1.2.2000001.192.168.0.103 = Hex-STRING: FC BD 67 E9 4A 21
...

[indy-independence]

Ideas for future gNMI/gRPC support: instead of polling the ARP table via SNMP at regular intervals you could subscribe to events when new ARP entries are added and query via:

gnmic> get --path /interfaces/interface[name=*]/subinterfaces/subinterface[index=*]/ipv4/neighbors/neighbor/state[origin=DYNAMIC]
Get Response:
[
  {
    "time": "1970-01-01T01:00:00+01:00",
    "updates": [
      {
        "Path": "interfaces/interface[name=Ethernet49/1]/subinterfaces/subinterface[index=0]/ipv4/neighbors/neighbor[ip=10.101.1.2]/state",
        "values": {
          "interfaces/interface/subinterfaces/subinterface/ipv4/neighbors/neighbor/state": {
            "openconfig-if-ip:ip": "10.101.1.2",
            "openconfig-if-ip:link-layer-address": "fc:bd:67:d0:e6:bd",
            "openconfig-if-ip:origin": "DYNAMIC"
          }
        }
      },
      {
        "Path": "interfaces/interface[name=Ethernet50/1]/subinterfaces/subinterface[index=0]/ipv4/neighbors/neighbor[ip=10.101.1.10]/state",
        "values": {
          "interfaces/interface/subinterfaces/subinterface/ipv4/neighbors/neighbor/state": {
            "openconfig-if-ip:ip": "10.101.1.10",
            "openconfig-if-ip:link-layer-address": "fc:bd:67:d0:fb:5d",
            "openconfig-if-ip:origin": "DYNAMIC"
          }
        }
      }
    ]
  }
]

I haven't figured out to do this VRF aware yet however..

[SpaceFarmer]

Stockholm University would like to have this feature as well.

[lunkwill42]

This is much the same NAV does specifically for collecting BRIDGE-MIB on Cisco and Aruba devices. These vendors have multiple instances of this MIB, which are reachable through community indexing.

The actual data collection for IP<->MAC mappings is done by the arp plugin to ipdevpoll. It supports three different MIB variations to get the data: IP-MIB, (the deprecated) IPV6-MIB and (the proprietary) CISCO-IETF-IP-MIB.

Hopefully, assuming Arista only supports the latest revisions of IP-MIB, we could get away with adding support for community indexing only in this MIB. We need something similar to this utility function NAV uses to detect alternate BRIDGE-MIB instances:

nav/python/nav/ipdevpoll/utils.py

Lines 146 to 156 in 4c9e477

	def get_dot1d_instances(agentproxy):
	"""
	Gets a list of alternative BRIDGE-MIB instances from a Cisco or Aruba
	agent.
	First
	:returns: A list of [(description, community), ...] for each alternate
	BRIDGE-MIB instance.
	"""

I will need to investigate further to see if there are more opportunities for code reuse here.

[lunkwill42]

There is of course this utility class which we definitely will need here:

nav/python/nav/mibs/mibretriever.py

Lines 574 to 586 in 770504d

	class MultiMibMixIn(MibRetriever):
	"""Queries and chains the results of multiple MIB instances using
	community indexing.
	Useful for Cisco devices, whose SNMP agents employ multiple BRIDGE-MIB
	instances, one for each active VLAN, each indexable via a modified SNMP
	community.
	Add the mixin to the list of base classes of a MibRetriever descendant
	class, and override any querying method that should work across multiple
	instances. The overriden method should use a call to self._multiquery().
	"""