Send netdisco-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: IBM BNT device version number problem (Jeroen van Ingen)
2. Re: IBM BNT device version number problem (Andy Ruhl)
3. Re: SSHCollector Issues (Graybeal, Andrew C.)
4. Re: SSHCollector Issues (Oliver Gorwits)
5. Re: SSHCollector Issues (Graybeal, Andrew C.)
6. Re: SSHCollector Issues (Oliver Gorwits)
7. Arpnip polling L2 switches (Cavaness, Matt)
--- Begin Message ---
Sorry, this is an OS version, not model number problem as the previous
subject states.
Some more info. Here is discover with -DISQ for the device that works:
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
Here's the same info for one that doesn't:
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
/home/netdisco/perl5/lib/perl5/App/Netdisco/Core/Discover.pm line 152.
That's the wrong MIB file for that device. I put the correct MIB files
in the netdisco-mibs/ibm directory. How do I get netdisco to use the
correct one? Is that even the problem?
SNMP::Info determines what SNMP objects to query for each device, eg to
determine the os_ver.
Looks like all three IBM switch models are classified as
SNMP::Info::Layer3::IBMGbTor devices, which always requests the object
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0
(.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0) to determine the software version.
The IBM-GbTOR-10G-L2L3-MIB in netdisco-mibs however seems specific to
the G8124 model.
What MIBs should be used for models other than the G8124 ? They would
have to be included in netdisco-mibs and SNMP::Info has to be updated to
use the correct MIBs and objects for each model.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
--- End Message ---
--- Begin Message ---
On Tue, May 12, 2015 at 8:35 AM, Jeroen van Ingen <
[email protected]> wrote:
> SNMP::Info determines what SNMP objects to query for each device, eg to
> determine the os_ver.
>
> Looks like all three IBM switch models are classified as
> SNMP::Info::Layer3::IBMGbTor devices, which always requests the object
> IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0
> (.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0) to determine the software version.
>
> The IBM-GbTOR-10G-L2L3-MIB in netdisco-mibs however seems specific to
> the G8124 model.
>
> What MIBs should be used for models other than the G8124 ? They would
> have to be included in netdisco-mibs and SNMP::Info has to be updated to
> use the correct MIBs and objects for each model.
>
Thanks!
The G8052 and G8264 firmware comes with the MIB files. I put them in the
netdisco-mibs directory but I was unaware that I had to do something else.
I'm trying to figure out SNMP::Info but not getting very far. Can you point
me in the right direction?
Andy
--- End Message ---
--- Begin Message ---
So I guess what I need to do is to manually add a device that cannot be
discovered?
I'm going to use SSH collector to get the arp cache from the ASA. The IP
address that I'm going to SSH to will never be discovered by Netdisco. It looks
like the old 1.x release used to have a "-F" or "--discoverfile" option to do
this.
Is there a solution for this scenario - Get arp cache entries into Netdisco
from a device that isn't discoverable via SNMP?
-----Original Message-----
From: Oliver Gorwits [mailto:[email protected]]
Sent: Thursday, April 23, 2015 1:38 PM
To: [email protected]
Subject: Re: [Netdisco] SSHCollector Issues
Hi Andrew,
On 2015-04-20 21:08, Graybeal, Andrew C. wrote:
> Random thought - does the device I'm collecting from need to be
> "discovered" or exist in the DB already in some way? Do I need to do
> the manual topology import?
Certainly, the device will need to exist (be discovered) in Netdisco prior to
the sshcollector run.
Perhaps run the script with DBIC_TRACE=1 in the environment to see what's
happening with the database.
regards,
oliver.
--- End Message ---
--- Begin Message ---
On 2015-05-13 21:20, Graybeal, Andrew C. wrote:
So I guess what I need to do is to manually add a device that cannot
be discovered?
I'm going to use SSH collector to get the arp cache from the ASA. The
IP address that I'm going to SSH to will never be discovered by
Netdisco. It looks like the old 1.x release used to have a "-F" or
"--discoverfile" option to do this.
By any chance is it discoverable on another IP? (even if not the same
IP as you would collect the ARP from)
regards,
oliver.
--- End Message ---
--- Begin Message ---
I don't believe so - we currently are not allowing Netdisco to poll the ASA
with SNMP and also ASAs in general don't support CDP.
Netdisco just sees the ASA as a node connected to devices that are discoverable.
Maybe I could stand up a Linux system which grabs the ARP cache from the ASA,
populate its own ARP cache with them, set-up an SNMP daemon that's discoverable
by Netdisco, then poll that system via SSH? That seems like overkill for
something like this.
I could also insert the MAC/IP pairings into the DB manually, but that's a
really sloppy way of doing this.
I guess I could enable SNMP polling on that device, I was just curious if I
could accomplish this without doing that.
-----Original Message-----
From: Oliver Gorwits [mailto:[email protected]]
Sent: Wednesday, May 13, 2015 4:26 PM
To: [email protected]
Subject: Re: [Netdisco] SSHCollector Issues
On 2015-05-13 21:20, Graybeal, Andrew C. wrote:
> So I guess what I need to do is to manually add a device that cannot
> be discovered?
>
> I'm going to use SSH collector to get the arp cache from the ASA. The
> IP address that I'm going to SSH to will never be discovered by
> Netdisco. It looks like the old 1.x release used to have a "-F" or
> "--discoverfile" option to do this.
By any chance is it discoverable on another IP? (even if not the same
IP as you would collect the ARP from)
regards,
oliver.
--- End Message ---
--- Begin Message ---
On 2015-05-13 22:12, Graybeal, Andrew C. wrote:
I don't believe so - we currently are not allowing Netdisco to poll
the ASA with SNMP and also ASAs in general don't support CDP.
Netdisco just sees the ASA as a node connected to devices that are
discoverable.
Okay, thanks for answering anyway.
So, another thought... Netdisco has the concept of pseudo (fake)
devices that can be created to link together two other devices (e.g. a
hub, etc). You go to Admin -> Pseudo Device, and create the device.
First I'd try doing that and seeing if netdisco-sshcollector works.
If not... go into the database and change the vendor field in the
device table from "netdisco" to whatever you like. This changes the
device from pseudo to "real". Then also add that device to discover_no,
macsuck_no, arpnip_no. Then try the sshcollector again.
Good luck!
regards,
oliver.
--- End Message ---
--- Begin Message ---
Hello,
I'm running into an issue where Arpnip is polling ARP tables on layer 2
switches. The result is that when admins SSH to the switch management, Arpnip
correlates the MAC address of the connected admin to the MAC address of the
upstream router.
I'm not 100% sure, but I believe the issue is being caused by the wrong SNMP
class being used. All of our layer 2 switches (all Cisco, a mix of 2960, 3560,
3750 and 3850) were detected as SNMP::Info::Layer3::C6500. In spite of this,
the device info page only shows layer 2 capabilities.
The problem is largely fixable by applying the "ip default-gateway" command on
the switches, but my feeling is they should be detected as L2 and therefore not
have their ARP tables polled.
We're running 2.032003, but have seen this behavior in every 2.x version. We
have an ancient 1.0 instance running against the same switches that doesn't
have the problem.
Thoughts or suggestions? Thanks in advance!
-Matt
--- End Message ---
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
