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: Issue with Netdisco arpnip on Cisco L3 Switches (Ye Xiong)
--- Begin Message ---
Hi Muris,
I don’t know Netdisco can do ssh to the switches. I will try that for sure.
Thanks for your reply.
Have a good one!
Thanks,
Xiong, Ye
Network Administrator
Network Services, IITS
Concordia University
From: Muris <alcat...@gmail.com>
Sent: December 2, 2024 9:39 PM
To: Ye Xiong <ye.xi...@concordia.ca>
Cc: Oliver Gorwits <oli...@cpan.org>; netdisco-users@lists.sourceforge.net
Subject: Re: [Netdisco] Issue with Netdisco arpnip on Cisco L3 Switches
Attention This email originates from outside the concordia.ca domain. // Ce
courriel provient de l'extérieur du domaine de concordia.ca
Hi Ye, i was saying that the existing SNMP class in netdisco may need to be
modified for that oid as well or a new one created, Oliver can probably answer
it as im still new to the workings behind it.
I was more meaning, you can use in your netdisco config to ssh to the devices
instead and grab arptables using ssh collector. The modifications just need to
be placed in deployment.yml file.
Once it reaches the arp stage it connects via ssh to device grabs arps then
stores it in the database.
Regards,
Muris
On 3 Dec 2024, at 12:58, Ye Xiong
<ye.xi...@concordia.ca<mailto:ye.xi...@concordia.ca>> wrote:
Hi Muris,
Yes, SSH and the show ip arp command work fine. Could you provide more details
on how to utilize SNMP class information?
I also investigated the OID 1.3.6.1.2.1.3.1.1.2, which appears to be
deprecated, while the OID 1.3.6.1.2.1.4.35.1.3 (ipNetToPhysicalPhysAddress)
seems to be a more recent option.
Thanks,
Xiong, Ye
Network Administrator
Network Services, IITS
Concordia University
From: Muris <alcat...@gmail.com<mailto:alcat...@gmail.com>>
Sent: December 2, 2024 7:19 PM
To: Ye Xiong <ye.xi...@concordia.ca<mailto:ye.xi...@concordia.ca>>
Cc: Oliver Gorwits <oli...@cpan.org<mailto:oli...@cpan.org>>;
netdisco-users@lists.sourceforge.net<mailto:netdisco-users@lists.sourceforge.net>
Subject: Re: [Netdisco] Issue with Netdisco arpnip on Cisco L3 Switches
Attention This email originates from outside the concordia.ca domain. // Ce
courriel provient de l'extérieur du domaine de concordia.ca
Hi Ye, considering that SNMPv2-SMI seems to get the mac/ip date, perhaps a SNMP
class for these devices is required that uses this one.
In the mean time, have you tried a SSH arpnip if that returns results?
Muris
From: Ye Xiong <ye.xi...@concordia.ca<mailto:ye.xi...@concordia.ca>>
Date: Tuesday 3 December 2024 at 10:25
To: Muris <alcat...@gmail.com<mailto:alcat...@gmail.com>>
Cc: Oliver Gorwits <oli...@cpan.org<mailto:oli...@cpan.org>>,
"netdisco-users@lists.sourceforge.net<mailto:netdisco-users@lists.sourceforge.net>"
<netdisco-users@lists.sourceforge.net<mailto:netdisco-users@lists.sourceforge.net>>
Subject: RE: [Netdisco] Issue with Netdisco arpnip on Cisco L3 Switches
Hi Muris,
They are C9500-24Y and WS-C4500X, but not of these models have issue. And yes,
it has multiple vrfs on it, no mpls.
Thanks,
Ye
From: Muris <alcat...@gmail.com<mailto:alcat...@gmail.com>>
Sent: December 2, 2024 4:03 PM
To: Ye Xiong <ye.xi...@concordia.ca<mailto:ye.xi...@concordia.ca>>
Cc: Oliver Gorwits <oli...@cpan.org<mailto:oli...@cpan.org>>;
netdisco-users@lists.sourceforge.net<mailto:netdisco-users@lists.sourceforge.net>
Subject: Re: [Netdisco] Issue with Netdisco arpnip on Cisco L3 Switches
Attention This email originates from outside the concordia.ca domain. // Ce
courriel provient de l'extérieur du domaine de concordia.ca
Hi Ye, what model switch? Are you running mpls/vrfs on it?
Regards,
Muris
On 3 Dec 2024, at 02:32, Ye Xiong
<ye.xi...@concordia.ca<mailto:ye.xi...@concordia.ca>> wrote:
Hi Oliver,
I hope this message finds you well.
I've been using Netdisco for some time and recently found an issue where the
arpnip command doesn’t work for some of our Cisco Layer 3 switches. Below is
the output from the netdisco-do arpnip command:
netdisco-do arpnip -d DEVICE_IP -D
[765768] 2024-12-02 15:22:30 info App::Netdisco version 2.079001 loaded.
[765768] 2024-12-02 15:22:30 info arpnip: [DEVICE_IP] started at Mon Dec 2
10:22:30 2024
[765768] 2024-12-02 15:22:30 debug arpnip: running with timeout 600s
[765768] 2024-12-02 15:22:30 debug //// CHECK \\\\ phase
[765768] 2024-12-02 15:22:30 debug ⮕ worker Internal::BackendFQDN p1000000
[765768] 2024-12-02 15:22:30 debug ⮕ worker Internal::SNMPFastDiscover p1000000
[765768] 2024-12-02 15:22:30 debug running with configured SNMP timeouts
[765768] 2024-12-02 15:22:30 debug ⮕ worker Arpnip p0
[765768] 2024-12-02 15:22:30 debug ⬅ (done) arpnip is able to run
[765768] 2024-12-02 15:22:30 debug //// EARLY \\\\ phase
[765768] 2024-12-02 15:22:30 debug ⮕ worker Arpnip::Nodes p0 "prepare common
data"
[765768] 2024-12-02 15:22:30 debug //// MAIN \\\\ phase
[765768] 2024-12-02 15:22:30 debug ⮕ worker Arpnip::Nodes p1000000
[765768] 2024-12-02 15:22:30 debug ⬅ (info) skip: arp table data supplied by
other source
[765768] 2024-12-02 15:22:30 debug ⮕ worker Arpnip::Nodes p200
[765768] 2024-12-02 15:22:30 debug ⬅ (info) skip: driver or action not
applicable
[765768] 2024-12-02 15:22:30 debug ⮕ worker Arpnip::Nodes p100
[765768] 2024-12-02 15:22:30 debug snmp reader cache warm: [DEVICE_IP]
[765768] 2024-12-02 15:22:30 debug [DEVICE_IP:161] try_connect with v: 2, t:
0.2, r: 0, class: SNMP::Info::Layer3::CiscoSwitch, comm: <hidden>
[765768] 2024-12-02 15:22:31 debug ⬅ (done) Gathered arp caches from DEVICE_IP
[765768] 2024-12-02 15:22:31 debug ⮕ worker Arpnip::Subnets p100
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/24
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/23
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/28
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/24
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/25
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/24
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/23
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/24
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/29
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - found subnet xx/30
[765768] 2024-12-02 15:22:31 debug ⬅ (info) [DEVICE_IP] arpnip - processed 28
Subnet entries
[765768] 2024-12-02 15:22:31 debug //// STORE \\\\ phase
[765768] 2024-12-02 15:22:31 debug ⮕ worker Arpnip::Nodes p0
[765768] 2024-12-02 15:22:31 debug resolving 0 ARP entries with max 250
outstanding requests
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - processed 0 ARP Cache
entries
[765768] 2024-12-02 15:22:31 debug [DEVICE_IP] arpnip - processed 0 IPv6
Neighbor Cache entries
[765768] 2024-12-02 15:22:31 debug ⬅ (done) Ended arpnip for DEVICE_IP
[765768] 2024-12-02 15:22:31 debug //// LATE \\\\ phase
[765768] 2024-12-02 15:22:31 debug ⮕ worker Arpnip::Hooks p0
[765768] 2024-12-02 15:22:31 debug ⬅ (info) [DEVICE_IP] hooks - 0 queued
[765768] 2024-12-02 15:22:31 info arpnip: finished at Mon Dec 2 10:22:31 2024
[765768] 2024-12-02 15:22:31 info arpnip: status done: Ended arpnip for
DEVICE_IP
As you can see, the debug log indicates that 0 ARP entries were resolved. But
when I performed an snmpwalk on the device, I was able to locate the ARP table
under the IP-MIB::ipNetToPhysicalPhysAddress instance.
On devices where the arpnip command works correctly, attempting an snmpwalk
with IP-MIB::ipNetToPhysicalPhysAddress yields:
snmpwalk -v2c -c COMMUNITYS DEVICE_IP IP-MIB::ipNetToPhysicalPhysAddress
IP-MIB::ipNetToPhysicalPhysAddress = No Such Instance currently exists at this
OID
But using the OID 1.3.6.1.2.1.3.1.1.2 reveals ARP table data in the following
format:
SNMPv2-SMI::mib-2.3.1.1.2.0.1.A.B.C.D = Hex-STRING: aa aa aa bb bb bb
Where A.B.C.D is the ip, aa aa aa bb bb bb is the mac address.
It seems there’s a discrepancy in how the ARP table data is accessed for these
devices. Do you have any suggestions or solutions to make arpnip work with
these switches?
Thanks in advance for your help!
Thanks,
Ye
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
