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: VLANs not discovered on Cisco Catalyst 1300 (Jason Garrett)
2. Re: Issue with Netdisco arpnip on Cisco L3 Switches (Muris)
--- Begin Message ---
Just checking in to see if the C1300 is supported yet? If not, do you
anticipate any issues getting full support? We are considering the purchase of
these switches (probably Q2 of 2025) but want to make sure they will work with
NetDisco.
Thanks!
Jason Garrett
Diocese of Lincoln Schools
Education Technology: (402) 473-0600
Email: jason-garr...@cdolinc.net<mailto:jason-garr...@cdolinc.net>
From: Oliver Gorwits <oli...@cpan.org>
Sent: Tuesday, October 29, 2024 6:27 AM
To: Koen Dooms <drhn...@gmail.com>
Cc: netdisco-users@lists.sourceforge.net
Subject: Re: [Netdisco] VLANs not discovered on Cisco Catalyst 1300
Hi again Diego and Koen
As mentioned by Muris, we can fix the model display with a MIB update which I'm
doing now.
I've also implemented a new SNMP::Info class for the C1300 devices so you get
the VLAN numbers and names. It can't be released just yet but will come with a
new Netdisco soonish.
thanks for the snapshots, a great help
regards
oliver.
On Mon, 28 Oct 2024 at 10:31, Koen Dooms
<drhn...@gmail.com<mailto:drhn...@gmail.com>> wrote:
Same here. Just installed C1300's.
The OS/version is reported back as 'catalyst/ ' instead of IOS. Although it is
not IOS, but a Linux based OS.
Regards,
Koen
Op ma 28 okt 2024 om 10:15 schreef Diego Barba García via netdisco-users
<netdisco-users@lists.sourceforge.net<mailto:netdisco-users@lists.sourceforge.net>>:
Hello,
We have been using netdisco for several years without major issues. Recently we
have configured a new cisco catalyst 1300 device, and we have noticed that, for
this device, netdisco doesn't discover the VLANs as it should. So, the switch
ports of this device appear without VLAN information. It discovers the VLANs as
"propVirtual" interfaces and the "VLAN membership" and "Native VLAN" are empty
on all physical ports. The issue only happens with catalyst 1300 devices.
Please, does anybody know if VLANs can be properly discovered on this
particular switch? Maybe something should be changed on the configuration of
netdisco (or on the switch) for enabling the discovery of VLANs on these
devices?
Best regards!
Diego
_______________________________________________
Netdisco mailing list
netdisco-users@lists.sourceforge.net<mailto:netdisco-users@lists.sourceforge.net>
https://sourceforge.net/p/netdisco/mailman/netdisco-users/
--
mvg,
Koen
_______________________________________________
Netdisco mailing list
netdisco-users@lists.sourceforge.net<mailto:netdisco-users@lists.sourceforge.net>
https://sourceforge.net/p/netdisco/mailman/netdisco-users/
CAUTION: This email originated from outside of the Diocese of Lincoln Email
System. Do not click links or open attachments unless you recognize the sender
and know the content is safe.
--- End Message ---
--- Begin Message ---
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> 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
