Send netdisco-users mailing list submissions to
netdisco-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
netdisco-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
netdisco-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: IP/MAC Mapping (Oliver Gorwits)
--- Begin Message ---
OK! good luck again :)
On Mon, 10 Jul 2023 at 13:39, Andy Millett <a...@unimatrixzero.co.uk> wrote:
> Hi Oliver,
>
> Thanks a lot for the response. It does look like the MPLS provider is
> limiting access to OID’s on their SNMP config.
>
> Here’s the output of the commands you mentioned
>
> netdisco@nms:~$ bin/netdisco-do show -D -d 172.31.2.167 -e
> ipNetToMediaPhysAddress
> [3294838] 2023-07-10 12:28:56 info App::Netdisco version 2.062002 loaded.
> [3294838] 2023-07-10 12:28:56 info show:
> [172.31.2.167]/ipNetToMediaPhysAddress started at Mon Jul 10 13:28:56 2023
> [3294838] 2023-07-10 12:28:56 debug show: running with timeout 600s
> [3294838] 2023-07-10 12:28:56 debug => running workers for phase: check
> [3294838] 2023-07-10 12:28:56 debug -> run worker check/0 "show"
> [3294838] 2023-07-10 12:28:56 debug Show is able to run
> [3294838] 2023-07-10 12:28:56 debug => running workers for phase: main
> [3294838] 2023-07-10 12:28:56 debug -> run worker main/100 "show"
> [3294838] 2023-07-10 12:28:56 debug snmp reader cache warm: [172.31.2.167]
> [3294838] 2023-07-10 12:28:56 debug [172.31.2.167:161] try_connect with
> ver: 2, class: SNMP::Info::Layer3::CiscoSwitch, comm: <hidden>
> undef
> [3294838] 2023-07-10 12:28:56 info show: finished at Mon Jul 10 13:28:56
> 2023
> [3294838] 2023-07-10 12:28:56 info show: status done: Showed
> ipNetToMediaPhysAddress response from 172.31.2.167
>
> netdisco@nms:~$ bin/netdisco-do show -D -d 172.31.2.167 -e
> ipNetToMediaNetAddress
> [3296138] 2023-07-10 12:29:19 info App::Netdisco version 2.062002 loaded.
> [3296138] 2023-07-10 12:29:19 info show:
> [172.31.2.167]/ipNetToMediaNetAddress started at Mon Jul 10 13:29:19 2023
> [3296138] 2023-07-10 12:29:19 debug show: running with timeout 600s
> [3296138] 2023-07-10 12:29:19 debug => running workers for phase: check
> [3296138] 2023-07-10 12:29:19 debug -> run worker check/0 "show"
> [3296138] 2023-07-10 12:29:19 debug Show is able to run
> [3296138] 2023-07-10 12:29:19 debug => running workers for phase: main
> [3296138] 2023-07-10 12:29:19 debug -> run worker main/100 "show"
> [3296138] 2023-07-10 12:29:19 debug snmp reader cache warm: [172.31.2.167]
> [3296138] 2023-07-10 12:29:19 debug [172.31.2.167:161] try_connect with
> ver: 2, class: SNMP::Info::Layer3::CiscoSwitch, comm: <hidden>
> undef
> [3296138] 2023-07-10 12:29:19 info show: finished at Mon Jul 10 13:29:19
> 2023
> [3296138] 2023-07-10 12:29:19 info show: status done: Showed
> ipNetToMediaNetAddress response from 172.31.2.167
>
> Now here’s a manual walk of ipNetToMediaPhysAddress
> and ipNetToMediaNetAddress
>
> netdisco@nms:~$ snmpwalk -v 2c -c com 172.31.2.167 1.3.6.1.2.1.4.22.1.2
> iso.3.6.1.2.1.4.22.1.2 = No Such Object available on this agent at this OID
>
> netdisco@nms:~$ snmpwalk -v 2c -c com 172.31.2.167 1.3.6.1.2.1.4.22.1.3
> iso.3.6.1.2.1.4.22.1.3 = No Such Object available on this agent at this OID
>
> I’ll take this up with the customer who can nudge the MPLS provider. Will
> report back if it’s still a problem.
>
> Best regards
> Andy
>
>
> On 10 Jul 2023, at 13:25, Oliver Gorwits <oli...@cpan.org> wrote:
>
> Hi again Andy
>
> OK so Netdisco is pretty much working fine, no issues there. There is some
> problem with the data from the device.
>
> The ARP table is two underlying SNMP tables, and you can dump them out
> with these commands:
>
> ~netdisco/bin/netdisco-do show -D -d 172.31.2.167 -e
> ipNetToMediaPhysAddress
> ~netdisco/bin/netdisco-do show -D -d 172.31.2.167 -e
> ipNetToMediaNetAddress
>
> If they are empty, then that is the problem! No data from the device.
>
> If they are not, and they look like they can give the required info, we
> might be able to code around the issue.
>
> I will be interested to see what you find, as you report several devices
> with the issue (perhaps try against different devices as well).
>
> Good luck
>
> Oliver.
>
> On Fri, 7 Jul 2023 at 18:56, Andy Millett <a...@unimatrixzero.co.uk>
> wrote:
>
>> Hi Oliver,
>>
>> My bad, sorry about that! Here you go.
>>
>> netdisco@tpe-librenms:~$ bin/netdisco-do arpnip -d 172.31.2.167 -D
>> [4059529] 2023-07-07 17:52:18 info App::Netdisco version 2.062002 loaded.
>> [4059529] 2023-07-07 17:52:18 info arpnip: [172.31.2.167] started at Fri
>> Jul 7 18:52:18 2023
>> [4059529] 2023-07-07 17:52:19 debug arpnip: running with timeout 600s
>> [4059529] 2023-07-07 17:52:19 debug => running workers for phase: check
>> [4059529] 2023-07-07 17:52:19 debug -> run worker check/0 "arpnip"
>> [4059529] 2023-07-07 17:52:19 debug arpnip is able to run
>> [4059529] 2023-07-07 17:52:19 debug => running workers for phase: early
>> [4059529] 2023-07-07 17:52:19 debug -> run worker early/0 "prepare common
>> data"
>> [4059529] 2023-07-07 17:52:19 debug => running workers for phase: main
>> [4059529] 2023-07-07 17:52:19 debug -> run worker main/1000000
>> "arpnip::nodes"
>> [4059529] 2023-07-07 17:52:19 debug skip: arp table data supplied by
>> other source
>> [4059529] 2023-07-07 17:52:19 debug -> run worker main/200 "arpnip::nodes"
>> [4059529] 2023-07-07 17:52:19 debug skip: driver or action not applicable
>> [4059529] 2023-07-07 17:52:19 debug -> run worker main/100 "arpnip::nodes"
>> [4059529] 2023-07-07 17:52:19 debug snmp reader cache warm: [172.31.2.167]
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167:161] try_connect with
>> ver: 2, class: SNMP::Info::Layer3::CiscoSwitch, comm: <hidden>
>> [4059529] 2023-07-07 17:52:19 debug -> run worker main/100
>> "arpnip::subnets"
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167] arpnip - found subnet
>> 100.64.0.0/30
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167] arpnip - found subnet
>> 10.219.212.0/24
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167] arpnip - found subnet
>> 10.219.212.0/24
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167] arpnip - processed 3
>> Subnet entries
>> [4059529] 2023-07-07 17:52:19 debug => running workers for phase: store
>> [4059529] 2023-07-07 17:52:19 debug -> run worker store/0 "arpnip::nodes"
>> [4059529] 2023-07-07 17:52:19 debug resolving 0 ARP entries with max 50
>> outstanding requests
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167] arpnip - processed 0
>> ARP Cache entries
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167] arpnip - processed 0
>> IPv6 Neighbor Cache entries
>> [4059529] 2023-07-07 17:52:19 debug => running workers for phase: late
>> [4059529] 2023-07-07 17:52:19 debug -> run worker late/0 "arpnip::hooks"
>> [4059529] 2023-07-07 17:52:19 debug [172.31.2.167] hooks - 0 queued
>> [4059529] 2023-07-07 17:52:19 info arpnip: finished at Fri Jul 7
>> 18:52:19 2023
>> [4059529] 2023-07-07 17:52:19 info arpnip: status done: Ended arpnip for
>> 172.31.2.167
>>
>> Best regards
>> Andy
>>
>>
>> On 7 Jul 2023, at 17:09, Oliver Gorwits <oli...@cpan.org> wrote:
>>
>> Hi Andy, you missed the -d out from the command so it failed. Please can
>> you run again?
>>
>> On Fri, 7 Jul 2023 at 16:34, Andy Millett <a...@unimatrixzero.co.uk>
>> wrote:
>>
>>> Hi Oliver,
>>>
>>> Thanks a lot for the response. Unfortunately, SSH isn’t an option here
>>> currently.
>>>
>>> Here’s the output of the netdisco-do command -
>>>
>>> netdisco@nms:~$ bin/netdisco-do arpnip 172.31.2.167 -D
>>> [3644811] 2023-07-07 15:30:07 info App::Netdisco version 2.062002
>>> loaded.
>>> [3644811] 2023-07-07 15:30:07 info arpnip: started at Fri Jul 7
>>> 16:30:07 2023
>>> [3644811] 2023-07-07 15:30:07 debug arpnip: running with timeout 600s
>>> [3644811] 2023-07-07 15:30:07 debug => running workers for phase: check
>>> [3644811] 2023-07-07 15:30:07 debug -> run worker check/0 "arpnip"
>>> [3644811] 2023-07-07 15:30:07 debug arpnip failed: unable to interpret
>>> device param
>>> [3644811] 2023-07-07 15:30:07 info arpnip: finished at Fri Jul 7
>>> 16:30:07 2023
>>> [3644811] 2023-07-07 15:30:07 info arpnip: status error: arpnip failed:
>>> unable to interpret device param
>>>
>>> The device concerned is a -
>>>
>>> Hardware
>>> Cisco 2921 (CISCO2921/K9)
>>> Operating System
>>> Cisco IOS 15.3(3)M10, RELEASE SOFTWARE (fc1) (UNIVERSALK9)
>>>
>>> Best regards
>>> Andy
>>>
>>>
>>> On 7 Jul 2023, at 15:22, Oliver Gorwits <oli...@cpan.org> wrote:
>>>
>>> Hi Andy
>>>
>>> We have seen that SNMP for ARP tables can be problematic on some
>>> platforms, and so Netdisco also supports SSH instead. It may be worth
>>> trying.
>>>
>>> Please see the docs here:
>>> https://github.com/netdisco/netdisco/wiki/Configuration#device_auth
>>> (see the parts about CLI driver and SSH, you have to add to config)
>>>
>>> And the list of platforms here (I guess IOS is relevant but maybe
>>> others):
>>>
>>> https://github.com/netdisco/netdisco/tree/master/lib/App/Netdisco/SSHCollector/Platform
>>>
>>> Another thought is if you're using VRFs and so far Netdisco doesn't have
>>> much support for that.
>>>
>>> Lastly you can enable debug and at the command line run the ARP gather
>>> job:
>>>
>>> ~netdisco/bin/netdisco-do arpnip -d 1.2.3.4 -D
>>>
>>> Do let me know how you get on,
>>>
>>> regards
>>> Oliver.
>>>
>>> On Fri, 7 Jul 2023 at 12:58, Andy Millett <a...@unimatrixzero.co.uk>
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I’ve got a really strange problem which has been around for a while,
>>>> but as we’re now doing Netbox/Netdisco integration with some customers is
>>>> causing some challenges. Basically, despite NetDisco querying a router’s
>>>> ARP table, with Arpnip we don’t see Netdisco making associations between IP
>>>> Address, and MAC address. So whilst I can search for a MAC address, and the
>>>> switch-port is returned, if I search for an IP Address for a node, nothing
>>>> is returned.
>>>>
>>>> Taking a PCAP of NetDisco performing an Arpnip, I can see it’s querying
>>>> the IP-MIB:ipNetToPhysicalTable, mappings are returned, none of this gets
>>>> into the database.
>>>>
>>>> The routers are mixed Cisco (ISR, ASR, 1921, 887, etc). Switches are
>>>> either Cisco or Juniper. Irrespective of switch vendor, no mapping of IP to
>>>> MAC is made unless the device is queried by Netdisco as part of the
>>>> inventory. The problem seems to be exclusively with Cisco routers, as sites
>>>> where a Juniper device is the gateway (either an SRX to an EX switch) we
>>>> see sound IP/MAC mappings in Netdisco.
>>>>
>>>> Any thoughts on this?
>>>>
>>>> Cheers
>>>> Andy
>>>>
>>>> _______________________________________________
>>>> Netdisco mailing list
>>>> netdisco-users@lists.sourceforge.net
>>>> https://sourceforge.net/p/netdisco/mailman/netdisco-users/
>>>
>>>
>>> _______________________________________________
>>> Netdisco mailing list
>>> netdisco-users@lists.sourceforge.net
>>> https://sourceforge.net/p/netdisco/mailman/netdisco-users/
>>
>>
>> _______________________________________________
>> Netdisco mailing list
>> netdisco-users@lists.sourceforge.net
>> https://sourceforge.net/p/netdisco/mailman/netdisco-users/
>
>
> _______________________________________________
> Netdisco mailing list
> netdisco-users@lists.sourceforge.net
> https://sourceforge.net/p/netdisco/mailman/netdisco-users/
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
