Menu
▾
▴
snmp-info-users — Mailing List for use and support of SNMP::Info
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
(11) |
Oct
(3) |
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(14) |
Mar
(11) |
Apr
|
May
(3) |
Jun
(4) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
(3) |
Nov
(20) |
Dec
(2) |
| 2005 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(4) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
(3) |
Dec
(2) |
| 2006 |
Jan
|
Feb
(5) |
Mar
(23) |
Apr
(4) |
May
(7) |
Jun
(32) |
Jul
(11) |
Aug
(9) |
Sep
(13) |
Oct
(12) |
Nov
(24) |
Dec
(34) |
| 2007 |
Jan
(14) |
Feb
(17) |
Mar
(8) |
Apr
(12) |
May
(1) |
Jun
(9) |
Jul
(9) |
Aug
|
Sep
(1) |
Oct
|
Nov
(9) |
Dec
(12) |
| 2008 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(10) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(7) |
Mar
(17) |
Apr
(2) |
May
(1) |
Jun
(9) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(16) |
Nov
(18) |
Dec
(1) |
| 2010 |
Jan
(1) |
Feb
(7) |
Mar
(11) |
Apr
(4) |
May
(10) |
Jun
|
Jul
(5) |
Aug
(21) |
Sep
(6) |
Oct
(4) |
Nov
(19) |
Dec
|
| 2011 |
Jan
|
Feb
(10) |
Mar
(4) |
Apr
(3) |
May
|
Jun
(5) |
Jul
(2) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
|
Dec
(4) |
| 2012 |
Jan
|
Feb
(6) |
Mar
(26) |
Apr
(2) |
May
(9) |
Jun
(9) |
Jul
(20) |
Aug
|
Sep
|
Oct
(5) |
Nov
(10) |
Dec
(11) |
| 2013 |
Jan
(1) |
Feb
(11) |
Mar
(2) |
Apr
(10) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(10) |
Sep
(4) |
Oct
(7) |
Nov
|
Dec
(3) |
| 2014 |
Jan
(3) |
Feb
|
Mar
|
Apr
(6) |
May
(12) |
Jun
(5) |
Jul
(6) |
Aug
(4) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
(3) |
| 2017 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(5) |
| 2019 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Oliver G. <ol...@cp...> - 2021-05-27 06:01:53
|
Hello all, *TL;DR ... please now connect to irc.libera.chat#netdisco* SNMP::Info has an Internet Relay Chat channel for our community to discuss netdisco and support its use (and each other). This channel has been hosted on the Freenode service, but is now moving across to the Libera service. The reason for this is that the owners of Freenode are taking steps which make it an unsuitable home for an open-source community such as ours. For more information see Google or else this blog post by someone I trust: https://diziet.dreamwidth.org/8514.html Here is a page to help those less familiar with the workings of IRC to make the move: https://meta.wikimedia.org/wiki/IRC/Migrating_to_Libera_Chat I'm sorry for the inconvenience, and thank you for using SNMP::Info! regards Oliver Gorwits. |
|
From: Tony G. <ton...@ui...> - 2021-05-04 03:38:40
|
Hello All,
I have been using netdisco to do device discovery on a variety of
devices and it has worked very well in most cases. I have come across
a device "ExtremeXOS (BD-8810)" which will not pull back any interface
(ports) or at least insert them to the device_port table, however we
know they exists when we query the ifTable directly. I'm attaching the
debug mode of netdisco discovery in hopes that maybe someone could help
me sport why? Or is this device just not supported?
Thanks in advance,
Tony
[netdisco@localhost logs]$ ~/bin/netdisco-do delete -d '172.31.1.10' |
delete-172.31.1.10.out
bash: delete-172.31.1.10.out: command not found
[13490] 2021-04-30 19:39:15 info App::Netdisco version 2.042010 loaded.
[13490] 2021-04-30 19:39:15 info delete: [172.31.1.10] started at Fri
Apr 30 19:39:15 2021
[13490] 2021-04-30 19:39:15 info delete: finished at Fri Apr 30
19:39:15 2021
[13490] 2021-04-30 19:39:15 info delete: status done: Deleted device:
172.31.1.10
[netdisco@localhost logs]$ ~/bin/netdisco-do discover -DISQ -d
'172.31.1.10' | tee discover-172.31.1.10.out
[14099] 2021-04-30 19:42:21 info App::Netdisco version 2.042010 loaded.
SELECT me.version, me.installed
FROM dbix_class_schema_versions me
WHERE 1 = 0
SELECT me.version
FROM dbix_class_schema_versions me
ORDER BY installed DESC
LIMIT '1'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE me.alias = '172.31.1.10' AND me.ip = '172.31.1.10'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE alias = '172.31.1.10'
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip, to_char( me.creation,
'YYYY-MM-DD HH24:MI' ), to_char( me.last_arpnip, 'YYYY-MM-DD HH24:MI' ),
to_char( me.last_discover, 'YYYY-MM-DD HH24:MI' ), to_char(
me.last_macsuck, 'YYYY-MM-DD HH24:MI' ), extract( epoch
FROM age( now( ), me.creation ) ), extract( epoch
FROM age( now( ), me.last_arpnip ) ), extract( epoch
FROM age( now( ), me.last_discover ) ), extract( epoch
FROM age( now( ), me.last_macsuck ) ), replace( age(
timestamp 'epoch'
+
me.uptime / 100 * interval '1 second', timestamp '1970-01-01
00:00:00-00' )
::te
xt, 'mon', 'month' )
FROM device me
WHERE me.ip = '172.31.1.10'
[14099] 2021-04-30 19:42:21 info discover: [172.31.1.10] started at
Fri Apr
30
19:42:21 2021
[14099] 2021-04-30 19:42:21 debug discover: running with timeout 60s
[14099] 2021-04-30 19:42:21 debug => running workers for phase: check
[14099] 2021-04-30 19:42:21 debug -> run worker check/_base_/0
[14099] 2021-04-30 19:42:21 debug Discover is able to run.
[14099] 2021-04-30 19:42:21 debug => running workers for phase: early
[14099] 2021-04-30 19:42:21 debug -> run worker early/properties/100
[14099] 2021-04-30 19:42:21 debug snmp reader cache warm: [172.31.1.10]
SELECT me.ip, me.snmp_comm_rw, me.snmp_auth_tag_read, me.snmp_auth_tag_write
FROM community me
WHERE me.ip = '172.31.1.10'
SELECT me.ip, me.snmp_comm_rw, me.snmp_auth_tag_read, me.snmp_auth_tag_write
FROM community me
WHERE me.ip = '172.31.1.10'
[14099] 2021-04-30 19:42:21 debug [172.31.1.10:161] try_connect with
ver: 3,
cla
ss: SNMP::Info, comm: <hidden>
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/3com
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/adtran
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/aerohive
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/alcatel
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/allied
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/apc
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/arista
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/aruba
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/asante
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/avaya
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/bluecoat
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/bluesocket
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/brother
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/cabletron
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ceragon
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/checkpoint
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ciena
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/cisco
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ciscosb
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/citrix
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/colubris
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/cyclades
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/d-link
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/dell
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/eaton
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/enterasys
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/etherwan
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/exinda
snmp_add_mib_dir: Failed to add /home/netdisco/netdisco-mibs/EXTRAS
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/extreme
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/extricom
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/f5
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/force10
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/fortinet
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/foundry
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/gigamon
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/h3c
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/hirschmann
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/hp
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/hpe
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/huawei
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ibm
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/juniper
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/lancom
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/lantronix
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/lenovo
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/liebert
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/mediant
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/meraki
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/meru
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/microsens
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/mikrotik
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/moser-baer
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/motorola
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/nateks
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/net-snmp
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netapp
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netgear
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netonix
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netscreen
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/nexans
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/nortel
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/northerndesign
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/oneaccess
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/opengear
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/packetfront
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/paloalto
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/pica8
snmp_add_mib_dir: Added mib dir
/home/netdisco/netdisco-mibs/pulsesecure-gateway
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/rad
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/redlionram
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/rfc
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/rittal
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/riverbed
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ruckus
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/schleifenbauer
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/sentry
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/siemens
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/sixnet
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/sonicwall
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/teleste
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/tplink
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/trapeze
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/vmware
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/xirrus
Read IF-MIB
Read SNMPv2-MIB
Read IP-MIB
SELECT me.ip, me.snmp_comm_rw, me.snmp_auth_tag_read, me.snmp_auth_tag_write
FROM community me
WHERE me.ip = '172.31.1.10'
INSERT INTO community( ip, snmp_auth_tag_read )
VALUES( '172.31.1.10', 'v3admin_172.31.1.10/32_' )
[14099] 2021-04-30 19:42:22 debug [172.31.1.10:161] try_connect with
ver: 3,
new
class: SNMP::Info::Layer3::Extreme, comm: <hidden>
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/3com
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/adtran
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/aerohive
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/alcatel
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/allied
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/apc
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/arista
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/aruba
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/asante
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/avaya
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/bluecoat
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/bluesocket
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/brother
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/cabletron
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ceragon
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/checkpoint
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ciena
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/cisco
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ciscosb
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/citrix
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/colubris
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/cyclades
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/d-link
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/dell
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/eaton
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/enterasys
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/etherwan
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/exinda
snmp_add_mib_dir: Failed to add /home/netdisco/netdisco-mibs/EXTRAS
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/extreme
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/extricom
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/f5
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/force10
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/fortinet
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/foundry
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/gigamon
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/h3c
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/hirschmann
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/hp
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/hpe
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/huawei
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ibm
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/juniper
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/lancom
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/lantronix
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/lenovo
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/liebert
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/mediant
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/meraki
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/meru
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/microsens
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/mikrotik
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/moser-baer
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/motorola
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/nateks
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/net-snmp
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netapp
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netgear
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netonix
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/netscreen
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/nexans
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/nortel
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/northerndesign
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/oneaccess
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/opengear
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/packetfront
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/paloalto
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/pica8
snmp_add_mib_dir: Added mib dir
/home/netdisco/netdisco-mibs/pulsesecure-gateway
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/rad
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/redlionram
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/rfc
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/rittal
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/riverbed
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/ruckus
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/schleifenbauer
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/sentry
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/siemens
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/sixnet
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/sonicwall
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/teleste
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/tplink
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/trapeze
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/vmware
snmp_add_mib_dir: Added mib dir /home/netdisco/netdisco-mibs/xirrus
Read MAU-MIB
Read ENTITY-MIB
Read EXTREME-FDB-MIB
Read EtherLike-MIB
Read LLDP-EXT-DOT3-MIB
Read RSTP-MIB
Read IP-MIB
Read LLDP-MIB
Read LLDP-EXT-DOT1-MIB
Read CISCO-IETF-IP-MIB
Read EXTREME-STP-EXTENSIONS-MIB
Read BRIDGE-MIB
Read IF-MIB
Read ADSL-LINE-MIB
Read EXTREME-VLAN-MIB
Read DOCS-IF-MIB
Read EXTREME-EDP-MIB
Read EXTREME-SYSTEM-MIB
Read OSPF-MIB
Read SNMPv2-MIB
Read BGP4-MIB
Read LLDP-EXT-MED-MIB
Read EXTREME-POE-MIB
Read ISIS-MIB
Read IANA-MAU-MIB
Read Q-BRIDGE-MIB
Read EXTREME-BASE-MIB
Read POWER-ETHERNET-MIB
Read DOCS-IF3-MIB
Read IPV6-MIB
error:snmp_translate_obj:Unknown OID vtp_d_name
error:snmp_translate_obj:Unknown OID ps1_type
error:snmp_translate_obj:Unknown OID ps2_type
error:snmp_translate_obj:Unknown OID slots
BEGIN WORK
INSERT INTO device( contact, description, fan, ip, last_discover,
layers, location, mac, model, name, os, os_ver, ports, ps1_status,
ps1_type, ps2_status,
ps2_t
ype, serial, slots, snmp_class, snmp_ver, uptime, vendor )
VALUES( 'su...@ex..., +1 888 257 3000', 'ExtremeXOS
(BD-8810) version 16.2.5.4 16.2.5.4-patch1-25 by release-manager on Wed
Jul 15 09:15:07
ED
T 2020', '101: OK, 102: OK, 103: OK, 104: OK, 105: OK, 106: OK, 107: OK,
108:
OK
, 109: OK', '172.31.1.10', now( ), '01001111', '',
'00:04:96:83:9c:4e',
'bd8810
', 'Core_A', 'xos', '16.2.5.4', '390', 'OK', NULL, 'OK', NULL,
'1321G-00747',
NU
LL, 'SNMP::Info::Layer3::Extreme', '3', '1867941300', 'extreme' )
COMMIT
[14099] 2021-04-30 19:42:24 debug -> run worker early/properties/100
[14099] 2021-04-30 19:42:24 debug -> run worker early/properties/100
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.20.128.
2
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.19.5.25
3
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.17.208.
2
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.19.1.25
3
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.19.4.25
3
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.29.2.2
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.31.1.10
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.29.3.4
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.17.200.
2
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
192.168.230
.1
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.17.216.
2
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.29.0.2
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.29.1.2
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.19.3.25
3
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.19.2.25
3
[14099] 2021-04-30 19:42:35 debug [172.31.1.10] device - aliased as
172.19.0.25
3
[14099] 2021-04-30 19:42:37 debug resolving 16 aliases with max 50
outstanding
requests
BEGIN WORK
DELETE FROM device_ip
WHERE ip = '172.31.1.10'
[14099] 2021-04-30 19:42:37 debug [172.31.1.10] device - removed 0 aliases
SAVEPOINT savepoint_0
INSERT INTO device_ip( alias, dns, ip, port, subnet )
VALUES( ?, ?, ?, ?, ? ) : '__BULK_INSERT__'
RELEASE SAVEPOINT savepoint_0
COMMIT
[14099] 2021-04-30 19:42:37 debug [172.31.1.10] aliases - added 16 new
aliases
[14099] 2021-04-30 19:42:37 debug -> run worker early/properties/100
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 : .1.3.6.1.2.1.1.7.0
SNMP::Info::_global description : SNMPv2-MIB::sysDescr.0 :
.1.3.6.1.2.1.1.1.0
SNMP::Info::_global id : SNMPv2-MIB::sysObjectID.0 : .1.3.6.1.2.1.1.2.0
SNMP::Info 3.70
SNMP::Info::device_type() layers:01001111 id:1916 sysDescr:"ExtremeXOS
(BD-8810) version 16.2.5.4 16.2.5.4-patch1-25 by release-manager on Wed
Jul 15 09:15:07 EDT 2020"
SNMP::Info 3.70
SNMP::Info::device_type() layers:01001111 id:1916 sysDescr:"ExtremeXOS
(BD-8810) version 16.2.5.4 16.2.5.4-patch1-25 by release-manager on Wed
Jul 15 09:15:07 EDT 2020"
SNMP::Info::_validate_autoload_method(vtp_d_name) Unable to resolve method.
SNMP::Info::_global description : SNMPv2-MIB::sysDescr.0 :
.1.3.6.1.2.1.1.1.0
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global name : SNMPv2-MIB::sysName.0 : .1.3.6.1.2.1.1.5.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 : .1.3.6.1.2.1.1.7.0
SNMP::Info::_global ports : IF-MIB::ifNumber.0 : .1.3.6.1.2.1.2.1.0
SNMP::Info::_global mac : BRIDGE-MIB::dot1dBaseBridgeAddress.0 :
.1.3.6.1.2.1.17.1.1.0
SNMP::Info::_validate_autoload_method(ps1_type) Unable to resolve method.
SNMP::Info::_validate_autoload_method(ps2_type) Unable to resolve method.
SNMP::Info::_global ps1_status_new :
EXTREME-SYSTEM-MIB::extremePowerSupplyStatus.1 :
.1.3.6.1.4.1.1916.1.1.1.27.1.2.1
SNMP::Info::_global ps2_status_new :
EXTREME-SYSTEM-MIB::extremePowerSupplyStatus.2 :
.1.3.6.1.4.1.1916.1.1.1.27.1.2.2
SNMP::Info::_load_attr fan_state :
EXTREME-SYSTEM-MIB::extremeFanOperational : .1.3.6.1.4.1.1916.1.1.1.9.1.2
SNMP::Info::_validate_autoload_method(slots) Unable to resolve method.
SNMP::Info::_global id : SNMPv2-MIB::sysObjectID.0 : .1.3.6.1.2.1.1.2.0
SNMP::Info::_load_attr e_parent : ENTITY-MIB::entPhysicalContainedIn :
.1.3.6.1.2.1.47.1.1.1.1.4
SNMP::Info::_load_attr e_class : ENTITY-MIB::entPhysicalClass :
.1.3.6.1.2.1.47.1.1.1.1.5
SNMP::Info::_load_attr e_serial : ENTITY-MIB::entPhysicalSerialNum(1) :
.1.3.6.1.2.1.47.1.1.1.1.11.1
SNMP::Info::_global contact : SNMPv2-MIB::sysContact.0 : .1.3.6.1.2.1.1.4.0
SNMP::Info::_global location : SNMPv2-MIB::sysLocation.0 :
.1.3.6.1.2.1.1.6.0
SNMP::Info::_load_attr old_ip_index : IP-MIB::ipAdEntIfIndex :
.1.3.6.1.2.1.4.20.1.2
SNMP::Info::_load_attr orig_i_name : IF-MIB::ifName :
.1.3.6.1.2.1.31.1.1.1.1
SNMP::Info::_load_attr orig_i_description : IF-MIB::ifDescr :
.1.3.6.1.2.1.2.2.1.2
SNMP::Info::_load_attr old_ip_netmask : IP-MIB::ipAdEntNetMask :
.1.3.6.1.2.1.4.20.1.3
SNMP::Info::_load_attr ip_addr6_index : IP-MIB::ipAddressIfIndex :
.1.3.6.1.2.1.4.34.1.3
SNMP::Info::_load_attr c_addr6_index :
CISCO-IETF-IP-MIB::cIpAddressIfIndex : .1.3.6.1.4.1.9.10.86.1.1.2.1.3
SNMP::Info::IPv6::ipv6_index: data comes from none of the MIBs.
SNMP::Info::_load_attr ip_addr6_index : IP-MIB::ipAddressIfIndex :
.1.3.6.1.2.1.4.34.1.3
SNMP::Info::_load_attr c_addr6_index :
CISCO-IETF-IP-MIB::cIpAddressIfIndex : .1.3.6.1.4.1.9.10.86.1.1.2.1.3
SNMP::Info::IPv6::ipv6_index: data comes from none of the MIBs.
SNMP::Info::_load_attr ip_addr6_type : IP-MIB::ipAddressType :
.1.3.6.1.2.1.4.34.1.4
SNMP::Info::_load_attr c_addr6_type : CISCO-IETF-IP-MIB::cIpAddressType
: .1.3.6.1.4.1.9.10.86.1.1.2.1.4
SNMP::Info::IPv6::ipv6_type: data comes from none of the MIBs.
SNMP::Info::_load_attr ip_addr6_pfx : IP-MIB::ipAddressPrefix :
.1.3.6.1.2.1.4.34.1.5
SNMP::Info::_load_attr c_addr6_pfx : CISCO-IETF-IP-MIB::cIpAddressPrefix
: .1.3.6.1.4.1.9.10.86.1.1.2.1.5
SNMP::Info::IPv6::ipv6_addr_prefixlength: data comes from none of the MIBs.
SNMP::Info::_load_attr i_type : IF-MIB::ifType : .1.3.6.1.2.1.2.2.1.3
SNMP::Info::_load_attr i_mtu : IF-MIB::ifMtu : .1.3.6.1.2.1.2.2.1.4
SNMP::Info::_load_attr orig_i_speed : IF-MIB::ifSpeed : .1.3.6.1.2.1.2.2.1.5
SNMP::Info::_load_attr i_speed_high : IF-MIB::ifHighSpeed :
.1.3.6.1.2.1.31.1.1.1.15
SNMP::Info::_load_attr i_mac : IF-MIB::ifPhysAddress : .1.3.6.1.2.1.2.2.1.6
SNMP::Info::_load_attr i_up : IF-MIB::ifOperStatus : .1.3.6.1.2.1.2.2.1.8
SNMP::Info::_load_attr i_up_admin : IF-MIB::ifAdmin[14099] 2021-04-30
19:43:21 debug -> HASH(0x428fec0)
[14099] 2021-04-30 19:43:21 debug {}
[14099] 2021-04-30 19:43:21 debug => running workers for phase: main
[14099] 2021-04-30 19:43:21 debug -> run worker main/canonicalip/100
[14099] 2021-04-30 19:43:21 debug -> run worker main/entities/100
BEGIN WORK
DELETE FROM device_module
WHERE ip = '172.31.1.10'
[14099] 2021-04-30 19:44:07 debug [172.31.1.10] modules - removed 0
chassis modules
SAVEPOINT savepoint_0
INSERT INTO device_module( class, description, fru, fw_ver, hw_ver,
index, ip, last_discover, model, name, parent, pos, serial, sw_ver, type )
VALUES( ?, ?, ?, ?, ?, ?, ?, now( ), ?, ?, ?, ?, ?, ?, ? ) :
'__BULK_INSERT__'
RELEASE SAVEPOINT savepoint_0
COMMIT
[14099] 2021-04-30 19:44:07 debug [172.31.1.10] modules - added 357
new chassis modules
[14099] 2021-04-30 19:44:07 debug -> run worker main/neighbors/100
BEGIN WORK
UPDATE device_port
SET manual_topo = false
WHERE ip = '172.31.1.10'
DELETE FROM topology
WHERE ( dev1 = '172.31.1.10' AND port1 NOT IN (
SELECT me.port
FROM device_port me
WHERE me.ip = '172.31.1.10'
) ) OR ( dev2 = '172.31.1.10' AND port2 NOT IN (
SELECT me.port
FROM device_port me
WHERE me.ip = '172.31.1.10'
) )
[14099] 2021-04-30 19:44:07 debug [172.31.1.10] neigh - removed 0
outdated manual topology links
[14099] 2021-04-30 19:44:07 debug [172.31.1.10] neigh - setting manual
topology links
SELECT me.dev1, me.port1, me.dev2, me.port2
FROM topology me
WHERE dev1 = '172.31.1.10' OR dev2 = '172.31.1.10'
COMMIT
error:snmp_translate_obj:Unknown OID hasCDP
error:snmp_translate_obj:Unknown OID hasSONMP
error:snmp_translate_obj:Unknown OID hasFDP
error:snmp_translate_obj:Unknown OID hasAMAP
error:snmp_translate_obj:Unknown OID hasCDP
error:snmp_translate_obj:Unknown OID hasSONMP
error:snmp_translate_obj:Unknown OID hasFDP
error:snmp_translate_obj:Unknown OID hasAMAP
error:snmp_translate_obj:Unknown OID hasCDP
error:snmp_translate_obj:Unknown OID hasSONMP
error:snmp_translate_obj:Unknown OID hasFDP
error:snmp_translate_obj:Unknown OID hasAMAP
error:snmp_translate_obj:Unknown OID hasCDP
error:snmp_translate_obj:Unknown OID hasSONMP
error:snmp_translate_obj:Unknown OID hasFDP
error:snmp_translate_obj:Unknown OID hasAMAP
error:snmp_translate_obj:Unknown OID hasCDP
error:snmp_translate_obj:Unknown OID hasSONMP
error:snmp_translate_obj:Unknown OID hasFDP
error:snmp_translate_obj:Unknown OID hasAMAP
Status : .1.3.6.1.2.1.2.2.1.7
SNMP::Info::_load_attr i_index : IF-MIB::ifIndex : .1.3.6.1.2.1.2.2.1.1
SNMP::Info::_load_attr i_alias : IF-MIB::ifAlias : .1.3.6.1.2.1.31.1.1.1.18
SNMP::Info::_load_attr entPhysicalDescr : ENTITY-MIB::entPhysicalDescr :
.1.3.6.1.2.1.47.1.1.1.1.2
SNMP::Info::_load_attr e_descr : ENTITY-MIB::entPhysicalDescr :
.1.3.6.1.2.1.47.1.1.1.1.2
SNMP::Info::_load_attr e_type : ENTITY-MIB::entPhysicalVendorType :
.1.3.6.1.2.1.47.1.1.1.1.3
SNMP::Info::_load_attr e_name : ENTITY-MIB::entPhysicalName :
.1.3.6.1.2.1.47.1.1.1.1.7
SNMP::Info::_load_attr e_pos : ENTITY-MIB::entPhysicalParentRelPos :
.1.3.6.1.2.1.47.1.1.1.1.6
SNMP::Info::_load_attr e_hwver : ENTITY-MIB::entPhysicalHardwareRev :
.1.3.6.1.2.1.47.1.1.1.1.8
SNMP::Info::_load_attr e_fwver : ENTITY-MIB::entPhysicalFirmwareRev :
.1.3.6.1.2.1.47.1.1.1.1.9
SNMP::Info::_load_attr e_swver : ENTITY-MIB::entPhysicalSoftwareRev :
.1.3.6.1.2.1.47.1.1.1.1.10
SNMP::Info::_load_attr e_model : ENTITY-MIB::entPhysicalModelName :
.1.3.6.1.2.1.47.1.1.1.1.13
SNMP::Info::_load_attr e_serial : ENTITY-MIB::entPhysicalSerialNum :
.1.3.6.1.2.1.47.1.1.1.1.11
SNMP::Info::_load_attr e_fru : ENTITY-MIB::entPhysicalIsFRU :
.1.3.6.1.2.1.47.1.1.1.1.16
SNMP::Info::_global lldp_sys_cap : LLDP-MIB::lldpLocSysCapEnabled.0 :
.1.0.8802.1.1.2.1.3.6.0
SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasSONMP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasFDP) Unable to resolve method.
SNMP::Info::_load_attr extremeEdpNeighborVlanIpAddress :
EXTREME-EDP-MIB::extremeEdpNeighborVlanIpAddress :
.1.3.6.1.4.1.1916.1.13.3.1.3
SNMP::Info::_validate_autoload_method(hasAMAP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasSONMP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasFDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasAMAP) Unable to resolve method.
SNMP::Info::_load_attr lldp_rem_pid : LLDP-MIB::lldpRemPortId :
.1.0.8802.1.1.2.1.4.1.1.7
SNMP::Info::_load_attr orig_bp_index : BRIDGE-MIB::dot1dBasePortIfIndex
: .1.3.6.1.2.1.17.1.4.1.2
SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasSONMP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasFDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasAMAP) Unable to resolve method.
SNMP::Info::_load_attr lldp_rem_desc : LLDP-MIB::lldpRemPortDesc :
.1.0.8802.1.1.2.1.4.1.1.8
SNMP::Info::_load_attr lldp_rem_pid : LLDP-MIB::lldpRemPortId :
.1.0.8802.1.1.2.1.4.1.1.7
SNMP::Info::_load_attr lldp_rem_pid_type :
LLDP-MIB::lldpRemPortIdSubtype : .1.0.8802.1.1.2.1.4.1.1.6
SNMP::Info::_load_attr lldp_rem_sysdesc : LLDP-MIB::lldpRemSysDesc :
.1.0.8802.1.1.2.1.4.1.1.10
SNMP::Info::_load_attr extremeEdpNeighborPort :
EXTREME-EDP-MIB::extremeEdpNeighborPort : .1.3.6.1.4.1.1916.1.13.2.1.6
SNMP::Info::_load_attr extremeEdpNeighborSlot :
EXTREME-EDP-MIB::extremeEdpNeighborSlot : .1.3.6.1.4.1.1916.1.13.2.1.5
SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasSONMP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasFDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasAMAP) Unable to resolve method.
SNMP::Info::_load_attr lldp_rem_id_type :
LLDP-MIB::lldpRemChassisIdSubtype : .1.0.8802.1.1.2.1.4.1.1.4
SNMP::Info::_load_attr lldp_rem_id : LLDP-MIB::lldpRemChassisId :
.1.0.8802.1.1.2.1.4.1.1.5
SNMP::Info::_load_attr edp_rem_sysname :
EXTREME-EDP-MIB::extremeEdpNeighborName : .1.3.6.1.4.1.1916.1.13.2.1.3
SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasSONMP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasFDP) Unable to resolve method.
SNMP::Info::_validate_autoload_method(hasAMAP) Unable to resolve method.
SNMP::Info::_load_attr lldp_rem_id : LLDP-MIB::lldpRemChassisId :
.1.0.8802.1.1.2.error:snmp_translate_obj:Unknown OID edp_platform
error:snmp_translate_obj:Unknown OID hasCDP
error:snmp_translate_obj:Unknown OID hasSONMP
error:snmp_translate_obj:Unknown OID hasFDP
error:snmp_translate_obj:Unknown OID hasAMAP
error:snmp_translate_obj:Unknown OID edp_cap
SELECT me.ip, me.port, me.creation, me.descr, me.up, me.up_admin,
me.type, me.duplex, me.duplex_admin, me.speed, me.name, me.mac, me.mtu,
me.stp, me.remote_ip, me.remote_port, me.remote_type, me.remote_id,
me.is_master, me.slave_of, me.manual_topo, me.is_uplink, me.vlan,
me.pvid, me.lastchange
FROM device_port me
WHERE me.ip = '172.31.1.10'
error:snmp_translate_obj:Unknown OID hasCDP
error:snmp_translate_obj:Unknown OID hasSONMP
error:snmp_translate_obj:Unknown OID hasFDP
error:snmp_translate_obj:Unknown OID hasAMAP
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip
FROM device me
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port
1:66 already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port
1:67 already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port
1:69 already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port
1:69 already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port
1:70 already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port
1:70 already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 3:3
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 3:3
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:2
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:2
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:2
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:3
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:5
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:5
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:5
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 5:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:2
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:2
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:2
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:4
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:5
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:5
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:5
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 6:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:1
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 7:2
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - local port 8:8
already skipped, ignoring
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - processed 0
neighbors
[14099] 2021-04-30 19:44:15 debug -> run worker main/neighbors/100
error:snmp_translate_obj:Unknown OID eigrp_peers
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE me.alias = '172.31.1.11' AND me.ip = '172.31.1.11'
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip, to_char( me.creation,
'YYYY-MM-DD HH24:MI' ), to_char( me.last_arpnip, 'YYYY-MM-DD HH24:MI' ),
to_char( me.last_discover, 'YYYY-MM-DD HH24:MI' ), to_char(
me.last_macsuck, 'YYYY-MM-DD HH24:MI' ), extract( epoch
FROM age( now( ), me.creation ) ), extract( epoch
FROM age( now( ), me.last_arpnip ) ), extract( epoch
FROM age( now( ), me.last_discover ) ), extract( epoch
FROM age( now( ), me.last_macsuck ) ), replace( age(
timestamp 'epoch' + me.uptime / 100 * interval '1 second', timestamp
'1970-01-01 00:00:00-00' ) ::text, 'mon', 'month' )
FROM device me
WHERE me.ip = '172.31.1.11'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE me.alias = '172.31.1.9' AND me.ip = '172.31.1.9'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE alias = '172.31.1.9'
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip, to_char( me.creation,
'YYYY-MM-DD HH24:MI' ), to_char( me.last_arpnip, 'YYYY-MM-DD HH24:MI' ),
to_char( me.last_discover, 'YYYY-MM-DD HH24:MI' ), to_char(
me.last_macsuck, 'YYYY-MM-DD HH24:MI' ), extract( epoch
FROM age( now( ), me.creation ) ), extract( epoch
FROM age( now( ), me.last_arpnip ) ), extract( epoch
FROM age( now( ), me.last_discover ) ), extract( epoch
FROM age( now( ), me.last_macsuck ) ), replace( age(
timestamp 'epoch' + me.uptime / 100 * interval '1 second', timestamp
'1970-01-01 00:00:00-00' ) ::text, 'mon', 'month' )
FROM device me
WHERE me.ip = '172.31.1.9'
BEGIN WORK
SAVEPOINT savepoint_0
INSERT INTO admin( action, device, device_key, port, status, subaction,
userip, username )
VALUES( ?, ?, ?, ?, ?, ?, ?, ? ) : '__BULK_INSERT__'
RELEASE SAVEPOINT savepoint_0
COMMIT
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] queue - queued
172.31.1.9 for discovery (peer)
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE me.alias = '172.17.200.3' AND me.ip = '172.17.200.3'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE alias = '172.17.200.3'
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip, to_char( me.creation,
'YYYY-MM-DD HH24:MI' ), to_char( me.last_arpnip, 'YYYY-MM-DD HH24:MI' ),
to_char( me.last_discover, 'YYYY-MM-DD HH24:MI' ), to_char(
me.last_macsuck, 'YYYY-MM-DD HH24:MI' ), extract( epoch
FROM age( now( ), me.creation ) ), extract( epoch
FROM age( now( ), me.last_arpnip ) ), extract( epoch
FROM age( now( ), me.last_discover ) ), extract( epoch
FROM age( now( ), me.last_macsuck ) ), replace( age(
timestamp 'epoch' + me.uptime / 100 * interval '1 second', timestamp
'1970-01-01 00:00:00-00' ) ::text, 'mon', 'month' )
FROM device me
WHERE me.ip = '172.31.1.11'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE me.alias = '192.168.230.2' AND me.ip = '192.168.230.2'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE alias = '192.168.230.2'
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip, to_char( me.creation,
'YYYY-MM-DD HH24:MI' ), to_char( me.last_arpnip, 'YYYY-MM-DD HH24:MI' ),
to_char( me.last_discover, 'YYYY-MM-DD HH24:MI' ), to_char(
me.last_macsuck, 'YYYY-MM-DD HH24:MI' ), extract( epoch
FROM age( now( ), me.creation ) ), extract( epoch
FROM age( now( ), me.last_arpnip ) ), extract( epoch
FROM age( now( ), me.last_discover ) ), extract( epoch
FROM age( now( ), me.last_macsuck ) ), replace( age(
timestamp 'epoch' + me.uptime / 100 * interval '1 second', timestamp
'1970-01-01 00:00:00-00' ) ::text, 'mon', 'month' )
FROM device me
WHERE me.ip = '172.31.1.11'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE me.alias = '172.17.200.5' AND me.ip = '172.17.200.5'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE alias = '172.17.200.5'
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip, to_char( me.creation,
'YYYY-MM-DD HH24:MI' ), to_char( me.last_arpnip, 'YYYY-MM-DD HH24:MI' ),
to_char( me.last_discover, 'YYYY-MM-DD HH24:MI' ), to_char(
me.last_macsuck, 'YYYY-MM-DD HH24:MI' ), extract( epoch
FROM age( now( ), me.creation ) ), extract( epoch
FROM age( now( ), me.last_arpnip ) ), extract( epoch
FROM age( now( ), me.last_discover ) ), extract( epoch
FROM age( now( ), me.last_macsuck ) ), replace( age(
timestamp 'epoch' + me.uptime / 100 * interval '1 second', timestamp
'1970-01-01 00:00:00-00' ) ::text, 'mon', 'month' )
FROM device me
WHERE me.ip = '172.17.200.5'
BEGIN WORK
SAVEPOINT savepoint_0
INSERT INTO admin( action, device, device_key, port, status, subaction,
userip, username )
VALUES( ?, ?, ?, ?, ?, ?, ?, ? ) : '__BULK_INSERT__'
RELEASE SAVEPOINT savepoint_0
COMMIT
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] queue - queued
172.17.200.5 for discovery (peer)
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE me.alias = '192.168.230.2' AND me.ip = '192.168.230.2'
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
WHERE alias = '192.168.230.2'
SELECT me.ip, me.creation, me.dns, me.description, me.uptime,
me.contact, me.name, me.location, me.layers, me.ports, me.mac,
me.serial, me.model, me.ps1_type, me.ps2_type, me.ps1_status,
me.ps2_status, me.fan, me.slots, me.vendor, me.os, me.os_ver, me.log,
me.snmp_ver, me.snmp_comm, me.snmp_class, me.vtp_domain,
me.last_discover, me.last_macsuck, me.last_arpnip, to_char( me.creation,
'YYYY-MM-DD HH24:MI' ), to_char( me.last_arpnip, 'YYYY-MM-DD HH24:MI' ),
to_char( me.last_discover, 'YYYY-MM-DD HH24:MI' ), to_char(
me.last_macsuck, 'YYYY-MM-DD HH24:MI' ), extract( epoch
FROM age( now( ), me.creation ) ), extract( epoch
FROM age( now( ), me.last_arpnip ) ), extract( epoch
FROM age( now( ), me.last_discover ) ), extract( epoch
FROM age( now( ), me.last_macsuck ) ), replace( age(
timestamp 'epoch' + me.uptime / 100 * interval '1 second', timestamp
'1970-01-01 00:00:00-00' ) ::text, 'mon', 'month' )
FROM device me
WHERE me.ip = '172.31.1.11'
[14099] 2021-04-30 19:44:15 debug [172.31.1.10] neigh - 2 peers added
to queue.
[14099] 2021-04-30 19:44:15 debug -> run worker main/portpower/100
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] power - 0 power modules
[14099] 2021-04-30 19:44:16 debug -> run worker main/portproperties/100
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:49 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:15 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:82 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 6:6 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 5:6 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:56 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 8:4 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:74 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:65 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:50 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:37 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:45 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:4 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port Cayenta rtif(172.17.208.2/21) already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port ipt2902 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:37 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port AdminFL1 rtif(172.19.1.253/24) already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:70 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:31 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:20 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:69 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:13 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 6:2 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port VirtualRouter0 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 5:2 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:78 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 7:4 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:25 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:21 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:51 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:67 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port securityvl already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:21 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port AdminFL2 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:55 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port guest_wired already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:87 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:7 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port AdminFL1 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:71 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:40 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:65 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:73 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:16 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:91 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:6 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:66 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:42 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:28 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port amitestvl already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 6:7 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:59 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port cem already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 6:3 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:8 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:20 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:80 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:3 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:83 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 7:7 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:24 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:86 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:19 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port security_nerc already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:10 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 8:7 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:46 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:52 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:49 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:90 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port VirtualRouter2 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:57 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port AdminFL2 rtif(172.19.2.253/24) already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port AdminFL3 rtif(172.19.3.253/24) already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port ESIP1 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:32 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:92 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port AdminFL4 rtif(172.19.4.253/24) already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:41 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:2 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:26 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:62 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:88 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:68 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:69 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:58 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:86 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:61 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:91 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:64 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:25 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:3 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:15 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:37 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:54 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port ISC_1 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port AdminBMT already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:48 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:83 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:73 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:45 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:17 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:61 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:62 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:29 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:54 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:42 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:33 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:57 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:5 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port eccsql already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:7 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port Corpvl rtif(172.17.200.2/21) already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 3:52 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port ILO already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 2:66 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] properties/speed -
local port 1:40 already skipped, ignoring
[14099] 2021-04-30 19:44:16 debug [172.31.1.10] propert...
[truncated message content] |
|
From: Oliver G. <ol...@cp...> - 2021-02-17 13:42:08
|
Hi Gerhard I would open a ticket here to ask: https://github.com/netdisco/snmp-info/issues regards Oliver On Thu, 28 Jan 2021 at 03:06, Gerhard Mourani <gmo...@gm...> wrote: > Hello, > > I'm using latest Netdisco version with my Cisco SB220 switches and no node > could be listed on the port interface column. Even the uplink interface > number are mixed. Someone has an idea about the problem or be able to make > these switches model work with Netdisco ? > > Regards, > _______________________________________________ > snmp-info-users mailing list > snm...@li... > https://lists.sourceforge.net/lists/listinfo/snmp-info-users > |
|
From: Gerhard M. <gmo...@gm...> - 2021-01-28 03:06:27
|
Hello, I'm using latest Netdisco version with my Cisco SB220 switches and no node could be listed on the port interface column. Even the uplink interface number are mixed. Someone has an idea about the problem or be able to make these switches model work with Netdisco ? Regards, |
|
From: Nico <nic...@gm...> - 2020-06-15 16:31:26
|
Hello, I'm a Netdot user. I want to get ARP tables from our F5, and I'm working on a script to retrieve it via CLI (already achieved more or less). When i was going to add ARP to it's due interface I noticed, there was only the physical interfaces (with interfaceVlans created), but not with vlans created as interfaces, where I could add an IP address and ARP table entries. I could add it all to the physical interfaces all bundled together, but would prefer to have it more fine grained. I noticed that: Without Info/Layer3/F5.pm, interfaces are retrieved from 1.3.6.1.2.1.2.2.1 (ifEntry) and there is one interface for each vlan, and also the physical interfaces (with a nice numeric index on them all). With F5.pm interfaces are retrieved from 1.3.6.1.4.1.3375.2.1.2.4.1.2.1, and there's only the physical interfaces (with a weird multidotted indexes). InterfaceVlans are populated just nicely for that Interfaces, but at least in Netdot I can't add IPs to interfaceVlans (to my knowledge). Also there's a table where vlan ip address can be retrieved (well they are selfips). At 1.3.6.1.4.1.3375.2.1.2.8.1.2.1, contains several tables one of wich is sysSelfIpVlanName, that can be used to relate the IP to the vlans. My knowledge of the F5 themselves is very limited (almost as much as my perl knowledge). So I don't know if it'lll be a good idea (or if it'll break something else), to try to modify F5.pm to: 1 - Present Vlans as interfaces, well using 1.3.6.1.2.1.2.2.1 or munching information from 1.3.6.1.4.1.3375.2.1.2.8.1.2.1 and 1.3.6.1.4.1.3375.2.1.2.13.1.1 (F5-BIGIP-SYSTEM-MIB.sysVlanTable). 2 - Assing the selfIP the F5 has in that vlan to that vlan interfaces Another thing I noticed is IP addresses themselves (in 1.3.6.1.4.1.3375.2.1.2.8.1.2.1.2) are presented (at least in our f5's) in a format i've never heard about before, called ipv4z (see https://www.ietf.org/rfc/rfc3291.txt for more information on ipv4z). An example of ipv4z is ffffffc0ffffffa810ffffffec00000003, that seems to correspond to 192.168.16.236. The netmask table is also affected by this "illnes". Still trying to figure out how to convert ipv4z to ipv4, but I guess that souln't be a problem. Best regards and thanks for any comment. -- Nico |
|
From: Oliver G. <ol...@cp...> - 2020-04-01 09:43:20
|
Hi Matthew Looks like i_speed_raw is global except for only the Layer3::Lenovo device class. Very interesting that you have this issue, the implementation is here if you wish to debug: https://github.com/netdisco/snmp-info/blob/master/lib/SNMP/Info.pm#L2461 regards oliver On Tue, 31 Mar 2020 at 17:25, Matthew Oatham via snmp-info-users < snm...@li...> wrote: > hi > > i_speed() returns speed munged - in human readable i.e. Ethernet1_8 - 10 > Gbps > if I want unmunged I use i_speed_raw() for the above I see Ethernet1_8 - > 10000000 > > however on some devices i_speed_raw() returns "10 Gbps" and not 10000000 > > is this function device specific? > > thanks > > > _______________________________________________ > snmp-info-users mailing list > snm...@li... > https://lists.sourceforge.net/lists/listinfo/snmp-info-users > |
|
From: Matthew O. <mat...@ya...> - 2020-03-31 16:24:58
|
hi i_speed() returns speed munged - in human readable i.e. Ethernet1_8 - 10 Gbps if I want unmunged I use i_speed_raw() for the above I see Ethernet1_8 - 10000000 however on some devices i_speed_raw() returns "10 Gbps" and not 10000000 is this function device specific? thanks |
|
From: Nick N. <nic...@aq...> - 2019-01-03 20:36:43
|
coolness.
bottom line is:
they took a copy of the lldp definitions, which they moved to another oid. if i had to guess, the only technical reason i can think of is that it's needed to enable seperation between different partitions on the netscaler. that's annoying but i can live with it. the bigger issue is that they did not copy the syntax definitions so now there's no way of knowing what the data means.'
for example:
lldp.mib defines "lldpRemPortIdSubtype" as being of type "LldpPortIdSubtype"
ns-mib-smiv2.mib defines "lldpRemPortIdSubtype" as being of type "Integer32".
the problem here is that, while "LldpPortIdSubtype" is in effect also just an integer, is has a lookup table defined:
SYNTAX INTEGER {
interfaceAlias(1),
portComponent(2),
macAddress(3),
networkAddress(4),
interfaceName(5),
agentCircuitId(6),
local(7)
}
so, defining an object as type "LldpPortIdSubtype" lets snmp clients know what each number means, how many options there are etc...
now, the netscaler version returns these exact same numbers, but since it's defined as an integer32 these don't mean anything.
for snmp::info & most other snmp clients this means they have to add workarounds so that they handle this specific item like it means something else.
for snmp::info in particular this means either changing the netscaler mib to use t(he right syntax, or handling all the valuemappings in the netscaler module. both of these are errorprone & laber intensive.
so if you want to get in touch with them for that, that would be real cool. if they can't change the syntax of their mib, which i can understand, perhaps they can also provide an alternative mib which uses the correct syntax. they'll alrdy doing so for what's up gold.
also noticed they actually have a github presence:
https://github.com/citrix/netscaler-snmp-oid-reference
i might creating a ticket there & see where i get.
// nick
-----Original Message-----
From: Mark Tinberg via snmp-info-users [mailto:snm...@li...]
Sent: Thursday, January 3, 2019 17:23
To: snm...@li...
Subject: Re: [snmp-info] using the lookups defined an unrelated mib on snmp results
On Wed, 2019-01-02 at 19:59 +0000, Nick Nauwelaerts wrote:
[snip]
>
> i'll let it sink in for a while, there are a few other things i'd like to
> work on first. 600 redlion routers with no snmp::info support might be
> more interesting as 2 netscalers :)
>
I too have a handful of NetScalers and ran into the same problem, if the
netscaler MIBs are loaded then I can't reliably query LLDP on our Cisco
access and aggregation devices because of the name conflicts confusing Net-
SNMP, and took the same fix action, ignoring the handful of b0rken devices
in favor of the larger number of working ones.
I think our relationship with Citrix is fine as far as I know so when I come
back to this issue I loop you in as you actually understand the technical
reasons for this better than I can and maybe with both of us pushing we can
get something to happen more quickly.
--
Mark Tinberg <mar...@wi...>
Division of Information Technology-Network Services
University of Wisconsin-Madison
_______________________________________________
snmp-info-users mailing list
snm...@li...
https://lists.sourceforge.net/lists/listinfo/snmp-info-users
________________________________
Volg Aquafin op Facebook<https://www.facebook.com/AquafinNV> | Twitter<https://twitter.com/aquafinnv> | YouTube<http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | LinkedIN<http://www.linkedin.com/company/aquafin/products>
In het kader van de uitoefening van onze taken verzamelen we bij Aquafin persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van de betrokkenen zijn, kan je nalezen in onze privacy policy<https://www.aquafin.be/nl-be/privacy-policy>.
P Denk aan het milieu. Druk deze mail niet onnodig af.
|
|
From: Mark T. <mar...@wi...> - 2019-01-03 17:22:53
|
On Wed, 2019-01-02 at 19:59 +0000, Nick Nauwelaerts wrote: [snip] > > i'll let it sink in for a while, there are a few other things i'd like to > work on first. 600 redlion routers with no snmp::info support might be > more interesting as 2 netscalers :) > I too have a handful of NetScalers and ran into the same problem, if the netscaler MIBs are loaded then I can't reliably query LLDP on our Cisco access and aggregation devices because of the name conflicts confusing Net- SNMP, and took the same fix action, ignoring the handful of b0rken devices in favor of the larger number of working ones. I think our relationship with Citrix is fine as far as I know so when I come back to this issue I loop you in as you actually understand the technical reasons for this better than I can and maybe with both of us pushing we can get something to happen more quickly. -- Mark Tinberg <mar...@wi...> Division of Information Technology-Network Services University of Wisconsin-Madison |
|
From: Nick N. <nic...@aq...> - 2019-01-02 19:59:31
|
well, our relation with citrix ain't that great. we got 2 netscalers, mpx5905's, 18months ago i, think which failed to do any ssl offloading for over a year due to buggy software. so we had 2 older models as a standin until 2 months ago, when a working software release was finally released. thing is, we need to go through our reseller to contact citrix, and i don't think i'm currently up for exchanging trouble tickets for multiple weeks :)
i was hoping there could be a way to trick snmp::mapenum or something to use an alternative value lookup, but i guess that was hoping to much that someone else would have already done the work. to make it even more annoying, sometimes they use the same name as lldp.mib, sometimes they use the same name but prefix it with "ns".
i also seem to remember that the order the mibs are loaded in matters, perhaps i can abuse that to use right translations.
i'll let it sink in for a while, there are a few other things i'd like to work on first. 600 redlion routers with no snmp::info support might be more interesting as 2 netscalers :)
// nick
-----Original Message-----
From: Jeroen van Ingen [mailto:j.v...@ut...]
Sent: Wednesday, January 2, 2019 15:00
To: snm...@li...
Subject: Re: [snmp-info] using the lookups defined an unrelated mib on snmp results
Hi Nick, list,
Don't you just love it when things are reinvented badly... I wonder why
Netscaler took this approach and doesn't simply support LLDP-MIB
(perhaps in parallel to their relocated version).
I can't think of a way to easily resolve this, except by the two ways
that you already mention: by adding munge functions to the device class,
or by modifying the MIBs.
Changing NS-ROOT-MIB itself would indeed make it harder to maintain (as
you've already noticed for a few other MIBs where have introduced
fixes), unless we can convince Citrix to incorporate our changes in a
new version.
We could try teaming up on this one; what if one of us creates the
improved NS-ROOT-MIB, logs a case at Citrix, gives the reference to the
other and the other also contacts Citrix to chime in on it?
What we could also try is adding the relevant objects to a separate MIB
file, with the translations. That way we don't have to change
NS-ROOT-MIB itself. For example, create updated versions of these
objects in "NS-LLDP-MIB" and reference that from the device class.
Regards,
Jeroen van Ingen, Network Engineer
University of Twente | Library, ICT Services & Archive (LISA)
P.O.Box 217, 7500 AE Enschede, The Netherlands
On 14-12-18 19:06, Nick Nauwelaerts wrote:
> cool, here's a fun question.
>
> i was having a go at updating the layer7/netscaler module. i've updated
> to ns-root-mib to the latest version i had available, pull request #61
> has been created in netdisco/netdisco-mibs.
>
> while having a look at the mib i noticed there was quite extensive lldp
> support present, so i had a go at trying to add that to the netscaler
> module. now comes the fun part. the netscaler doesnt support the normal
> lldp-mib, but they copied almost all of it to the ns-root-mib, most oids
> even have the same name. for example, you have both
> NS-ROOT-MIB::lldpLocSysName & LLDP-MIB::lldpLocSysName (as stated, the
> netscaler will not answer to lldp-mib requests).
>
> since almost all oids are present this could have made the lldp support
> a breeze. but now the problem:
>
> while the names match; the datatypes dont for several important objects.
>
> case in point:
>
> ns-root-mib::lldpRemChassisIdSubtype OBJECT-TYPE
>
> SYNTAX Integer32
>
> MAX-ACCESS read-only
>
> STATUS current
>
> DESCRIPTION
>
> "ChassisId subtype of remote system"
>
> ::= { nsLLDPRemEntry 3 }
>
> llldp-mib::lldpRemChassisIdSubtype OBJECT-TYPE
>
> SYNTAX LldpChassisIdSubtype
>
> MAX-ACCESS read-only
>
> STATUS current
>
> DESCRIPTION
>
> "The type of encoding used to identify the chassis associated
>
> with the remote system."
>
> REFERENCE
>
> "IEEE 802.1AB-2005 9.5.2.2"
>
> ::= { lldpRemEntry 4 }
>
> they took a shortcut & just made it an integer without any of the
> lookups the regular mib has. i think the easiest way to fix this is to
> force the use of the lookups defined in lldp-mib. is there some way to
> do this easily?
>
> backup plan would be to add a bunch of munge functions where i manually
> copy the datatypes from lldp-mib.
>
> option of last resort would be to change the datatypes in the
> ns-root-mib, but that seems errorprone. not to mention you need to not
> overwrite them with the next mib upgrade.
>
> any pointers?
>
> thx
>
> // nick
>
>
> ------------------------------------------------------------------------
>
> /Volg Aquafin op Facebook <https://www.facebook.com/AquafinNV> | Twitter
> <https://twitter.com/aquafinnv> | YouTube
> <http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> |
> LinkedIN <http://www.linkedin.com/company/aquafin/products> /
>
> In het kader van de uitoefening van onze taken verzamelen we bij Aquafin
> persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van
> de betrokkenen zijn, kan je nalezen in onze privacy policy
> <https://www.aquafin.be/nl-be/privacy-policy>.
>
> P Denk aan het milieu. Druk deze mail niet onnodig af.
_______________________________________________
snmp-info-users mailing list
snm...@li...
https://lists.sourceforge.net/lists/listinfo/snmp-info-users
|
|
From: Jeroen v. I. <j.v...@ut...> - 2019-01-02 14:00:32
|
Hi Nick, list,
Don't you just love it when things are reinvented badly... I wonder why
Netscaler took this approach and doesn't simply support LLDP-MIB
(perhaps in parallel to their relocated version).
I can't think of a way to easily resolve this, except by the two ways
that you already mention: by adding munge functions to the device class,
or by modifying the MIBs.
Changing NS-ROOT-MIB itself would indeed make it harder to maintain (as
you've already noticed for a few other MIBs where have introduced
fixes), unless we can convince Citrix to incorporate our changes in a
new version.
We could try teaming up on this one; what if one of us creates the
improved NS-ROOT-MIB, logs a case at Citrix, gives the reference to the
other and the other also contacts Citrix to chime in on it?
What we could also try is adding the relevant objects to a separate MIB
file, with the translations. That way we don't have to change
NS-ROOT-MIB itself. For example, create updated versions of these
objects in "NS-LLDP-MIB" and reference that from the device class.
Regards,
Jeroen van Ingen, Network Engineer
University of Twente | Library, ICT Services & Archive (LISA)
P.O.Box 217, 7500 AE Enschede, The Netherlands
On 14-12-18 19:06, Nick Nauwelaerts wrote:
> cool, here's a fun question.
>
> i was having a go at updating the layer7/netscaler module. i've updated
> to ns-root-mib to the latest version i had available, pull request #61
> has been created in netdisco/netdisco-mibs.
>
> while having a look at the mib i noticed there was quite extensive lldp
> support present, so i had a go at trying to add that to the netscaler
> module. now comes the fun part. the netscaler doesnt support the normal
> lldp-mib, but they copied almost all of it to the ns-root-mib, most oids
> even have the same name. for example, you have both
> NS-ROOT-MIB::lldpLocSysName & LLDP-MIB::lldpLocSysName (as stated, the
> netscaler will not answer to lldp-mib requests).
>
> since almost all oids are present this could have made the lldp support
> a breeze. but now the problem:
>
> while the names match; the datatypes dont for several important objects.
>
> case in point:
>
> ns-root-mib::lldpRemChassisIdSubtype OBJECT-TYPE
>
> SYNTAX Integer32
>
> MAX-ACCESS read-only
>
> STATUS current
>
> DESCRIPTION
>
> "ChassisId subtype of remote system"
>
> ::= { nsLLDPRemEntry 3 }
>
> llldp-mib::lldpRemChassisIdSubtype OBJECT-TYPE
>
> SYNTAX LldpChassisIdSubtype
>
> MAX-ACCESS read-only
>
> STATUS current
>
> DESCRIPTION
>
> "The type of encoding used to identify the chassis associated
>
> with the remote system."
>
> REFERENCE
>
> "IEEE 802.1AB-2005 9.5.2.2"
>
> ::= { lldpRemEntry 4 }
>
> they took a shortcut & just made it an integer without any of the
> lookups the regular mib has. i think the easiest way to fix this is to
> force the use of the lookups defined in lldp-mib. is there some way to
> do this easily?
>
> backup plan would be to add a bunch of munge functions where i manually
> copy the datatypes from lldp-mib.
>
> option of last resort would be to change the datatypes in the
> ns-root-mib, but that seems errorprone. not to mention you need to not
> overwrite them with the next mib upgrade.
>
> any pointers?
>
> thx
>
> // nick
>
>
> ------------------------------------------------------------------------
>
> /Volg Aquafin op Facebook <https://www.facebook.com/AquafinNV> | Twitter
> <https://twitter.com/aquafinnv> | YouTube
> <http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> |
> LinkedIN <http://www.linkedin.com/company/aquafin/products> /
>
> In het kader van de uitoefening van onze taken verzamelen we bij Aquafin
> persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van
> de betrokkenen zijn, kan je nalezen in onze privacy policy
> <https://www.aquafin.be/nl-be/privacy-policy>.
>
> P Denk aan het milieu. Druk deze mail niet onnodig af.
|
|
From: Nick N. <nic...@aq...> - 2018-12-14 18:06:31
|
cool, here's a fun question.
i was having a go at updating the layer7/netscaler module. i've updated to ns-root-mib to the latest version i had available, pull request #61 has been created in netdisco/netdisco-mibs.
while having a look at the mib i noticed there was quite extensive lldp support present, so i had a go at trying to add that to the netscaler module. now comes the fun part. the netscaler doesnt support the normal lldp-mib, but they copied almost all of it to the ns-root-mib, most oids even have the same name. for example, you have both NS-ROOT-MIB::lldpLocSysName & LLDP-MIB::lldpLocSysName (as stated, the netscaler will not answer to lldp-mib requests).
since almost all oids are present this could have made the lldp support a breeze. but now the problem:
while the names match; the datatypes dont for several important objects.
case in point:
ns-root-mib::lldpRemChassisIdSubtype OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"ChassisId subtype of remote system"
::= { nsLLDPRemEntry 3 }
llldp-mib::lldpRemChassisIdSubtype OBJECT-TYPE
SYNTAX LldpChassisIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of encoding used to identify the chassis associated
with the remote system."
REFERENCE
"IEEE 802.1AB-2005 9.5.2.2"
::= { lldpRemEntry 4 }
they took a shortcut & just made it an integer without any of the lookups the regular mib has. i think the easiest way to fix this is to force the use of the lookups defined in lldp-mib. is there some way to do this easily?
backup plan would be to add a bunch of munge functions where i manually copy the datatypes from lldp-mib.
option of last resort would be to change the datatypes in the ns-root-mib, but that seems errorprone. not to mention you need to not overwrite them with the next mib upgrade.
any pointers?
thx
// nick
________________________________
Volg Aquafin op Facebook<https://www.facebook.com/AquafinNV> | Twitter<https://twitter.com/aquafinnv> | YouTube<http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | LinkedIN<http://www.linkedin.com/company/aquafin/products>
In het kader van de uitoefening van onze taken verzamelen we bij Aquafin persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van de betrokkenen zijn, kan je nalezen in onze privacy policy<https://www.aquafin.be/nl-be/privacy-policy>.
P Denk aan het milieu. Druk deze mail niet onnodig af.
|
|
From: Nick N. <nic...@aq...> - 2018-12-06 15:43:42
|
ok,
so i added a hint to snmp::info under layer2 oids & discovery works .... half of the time.
Info.pm addition:
%l2sysoidmap ->
21091 => 'SNMP::Info::Layer2::Exinda',
the meat of the module is (git version not yet up to date):
(guess i can fold a few of these function to a reference under GLOBALS, just noticed that's a thing).
%MIBS = (
%SNMP::Info::Layer2::MIBS,
'EXINDA-MIB' => 'hardwareSeries',
'EXINDA-MIB' => 'systemHostId',
'EXINDA-MIB' => 'systemVersion',
'EXINDA-MIB' => 'systemUptime',
);
%GLOBALS = (
%SNMP::Info::Layer2::GLOBALS,
# EXINDA-MIB
'uptime' => 'systemUptime',
);
%FUNCS = (
%SNMP::Info::Layer2::FUNCS,
);
%MUNGE = (
%SNMP::Info::Layer2::MUNGE,
);
sub layers {
# layer 2: bridged shaping and failopen interfaces
# layer 3/4: ip and layer 4 protocol fiddling and accell
# layer 7: wccp supprt
return '01001110';
}
sub vendor {
return "exinda";
}
sub model {
my $exinda = shift;
return $exinda->hardwareSeries();
}
sub serial {
# exinda units have a hostid and serial,
# regretfully only hostid is exposed via snmp
my $exinda = shift;
return $exinda->systemHostId();
}
sub os {
return 'exos';
}
sub os_ver {
my $exinda = shift;
return $exinda->systemVersion();
}
uptime is an interesting one since since it differs from sysuptimeinstance.
now, here the interesting part.
i discover the device and show vendor and uptime:
netdisco-do discover -d 10.40.254.16
[29979] 2018-12-06 15:35:34 info App::Netdisco version 2.039033 loaded.
[29979] 2018-12-06 15:35:34 info discover: [10.40.254.16] started at Thu Dec 6 16:35:34 2018
[29979] 2018-12-06 15:35:35 info discover: finished at Thu Dec 6 16:35:35 2018
[29979] 2018-12-06 15:35:35 info discover: status done: Ended discover for 10.40.254.16
netdisco-do show -d 10.40.254.16 -e uptime -I
[29983] 2018-12-06 15:35:37 info App::Netdisco version 2.039033 loaded.
[29983] 2018-12-06 15:35:38 info show: [10.40.254.16]/uptime started at Thu Dec 6 16:35:38 2018
SNMP::Info::_global uptime : EXINDA-MIB::systemUptime.0 : .1.3.6.1.4.1.21091.1.1.5.0
SNMP::Info::_global description : SNMPv2-MIB::sysDescr.0 : .1.3.6.1.2.1.1.1.0
SNMP::Info::_global id : SNMPv2-MIB::sysObjectID.0 : .1.3.6.1.2.1.1.2.0
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001110 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001110 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
SNMP::Info::_global uptime : EXINDA-MIB::systemUptime.0 : .1.3.6.1.4.1.21091.1.1.5.0
654513766
[29983] 2018-12-06 15:35:38 info show: finished at Thu Dec 6 16:35:38 2018
[29983] 2018-12-06 15:35:38 info show: status done: Showed uptime response from 10.40.254.16
netdisco-do show -d 10.40.254.16 -e vendor -I
[29987] 2018-12-06 15:35:49 info App::Netdisco version 2.039033 loaded.
[29987] 2018-12-06 15:35:50 info show: [10.40.254.16]/vendor started at Thu Dec 6 16:35:50 2018
SNMP::Info::_global uptime : EXINDA-MIB::systemUptime.0 : .1.3.6.1.4.1.21091.1.1.5.0
SNMP::Info::_global description : SNMPv2-MIB::sysDescr.0 : .1.3.6.1.2.1.1.1.0
SNMP::Info::_global id : SNMPv2-MIB::sysObjectID.0 : .1.3.6.1.2.1.1.2.0
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001110 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001110 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
SNMP::Info::_global description : SNMPv2-MIB::sysDescr.0 : .1.3.6.1.2.1.1.1.0
SNMP::Info::_global id : SNMPv2-MIB::sysObjectID.0 : .1.3.6.1.2.1.1.2.0
"unknown"
[29987] 2018-12-06 15:35:50 info show: finished at Thu Dec 6 16:35:50 2018
[29987] 2018-12-06 15:35:50 info show: status done: Showed vendor response from 10.40.254.16
-> as you can see, uptime is corrert but, vendor is unknown.
now the interesting part, i just run discover on the device again:
netdisco-do discover -d 10.40.254.16
[29738] 2018-12-06 15:32:43 info App::Netdisco version 2.039033 loaded.
[29738] 2018-12-06 15:32:43 info discover: [10.40.254.16] started at Thu Dec 6 16:32:43 2018
[29738] 2018-12-06 15:32:44 info discover: finished at Thu Dec 6 16:32:44 2018
[29738] 2018-12-06 15:32:44 info discover: status done: Ended discover for 10.40.254.16
netdisco-do show -d 10.40.254.16 -e uptime -I
[29742] 2018-12-06 15:32:48 info App::Netdisco version 2.039033 loaded.
[29742] 2018-12-06 15:32:48 info show: [10.40.254.16]/uptime started at Thu Dec 6 16:32:48 2018
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance : .1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 : .1.3.6.1.2.1.1.7.0
SNMP::Info::_global description : SNMPv2-MIB::sysDescr.0 : .1.3.6.1.2.1.1.1.0
SNMP::Info::_global id : SNMPv2-MIB::sysObjectID.0 : .1.3.6.1.2.1.1.2.0
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001000 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001000 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance : .1.3.6.1.2.1.1.3.0
319684330
[29742] 2018-12-06 15:32:49 info show: finished at Thu Dec 6 16:32:49 2018
[29742] 2018-12-06 15:32:49 info show: status done: Showed uptime response from 10.40.254.16
netdisco-do show -d 10.40.254.16 -e vendor -I
[29746] 2018-12-06 15:32:51 info App::Netdisco version 2.039033 loaded.
[29746] 2018-12-06 15:32:51 info show: [10.40.254.16]/vendor started at Thu Dec 6 16:32:51 2018
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance : .1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 : .1.3.6.1.2.1.1.7.0
SNMP::Info::_global description : SNMPv2-MIB::sysDescr.0 : .1.3.6.1.2.1.1.1.0
SNMP::Info::_global id : SNMPv2-MIB::sysObjectID.0 : .1.3.6.1.2.1.1.2.0
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001000 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
SNMP::Info 3.63
SNMP::Info::device_type() layers:01001000 id:21091 sysDescr:"Linux exinda-8063 3.10.72-72EXINDAsmp #0 SMP @1484583999 x86_64"
"exinda"
[29746] 2018-12-06 15:32:52 info show: finished at Thu Dec 6 16:32:52 2018
[29746] 2018-12-06 15:32:52 info show: status done: Showed vendor response from 10.40.254.16
-> as you see uptime has now reverted to sysuptimeinstance, vendor has been changed to exinda & layers has been changed to 4+7
rerunning discover just repeats the known/unknown cycle.
any hints, do i need to add more references to Info.pm?
and why is vendor "unknown" when that's the time it's actually using the correct module??
// nick
-----Original Message-----
From: Jeroen van Ingen [mailto:j.v...@ut...]
Sent: Thursday, December 6, 2018 13:56
To: snm...@li...
Subject: Re: [snmp-info] adding new vendor support
Hi Nick,
The main SNMP::Info module needs /some/ way to get to the right device
class. Generally, adding the vendor ID to the Layer2 and/or Layer3
mapping table is enough (especially if there's only one device class for
that vendor).
Regards,
Jeroen van Ingen, Network Engineer
University of Twente | Library, ICT Services & Archive (LISA)
P.O.Box 217, 7500 AE Enschede, The Netherlands
On 06-12-18 13:39, Nick Nauwelaerts wrote:
> heya,
>
> i was wondering what step i missed in trying to add support for a new
> vendor.
>
> more specifally, exinda devices - vendor id 21091. netdisco discovers
> the device as enterprises.21091
>
> netdisco-do show -d 10.40.254.16 -e vendor
>
> [25000] 2018-12-06 12:33:06 info App::Netdisco version 2.039033 loaded.
>
> [25000] 2018-12-06 12:33:06 info show: [10.40.254.16]/vendor started at
> Thu Dec 6 13:33:06 2018
>
> "enterprises.21091"
>
> netdisco-do show -d 10.40.254.16 -e serial
>
> [25022] 2018-12-06 12:33:32 info App::Netdisco version 2.039033 loaded.
>
> [25022] 2018-12-06 12:33:32 info show: [10.40.254.16]/serial started at
> Thu Dec 6 13:33:32 2018
>
> undef
>
> however, when using the explicit leaf:
>
> netdisco-do show -d 10.40.254.16 -e Layer2::Exinda::serial
>
> [25057] 2018-12-06 12:34:04 info App::Netdisco version 2.039033 loaded.
>
> [25057] 2018-12-06 12:34:04 info show:
> [10.40.254.16]/Layer2::Exinda::serial started at Thu Dec 6 13:34:04 2018
>
> "109836a9a4a9"
>
> netdisco-do show -d 10.40.254.16 -e Layer2::Exinda::vendor
>
> [25064] 2018-12-06 12:34:16 info App::Netdisco version 2.039033 loaded.
>
> [25064] 2018-12-06 12:34:16 info show:
> [10.40.254.16]/Layer2::Exinda::vendor started at Thu Dec 6 13:34:16 2018
>
> "Exinda"
>
> i tried deleted, expiring & rediscovering the device but to no avail.
>
> the main snmp::info has a list of fallbacks defined, but i was under the
> impression that this was only needed when autodiscovery didnt work.
>
> thx
>
> // nick
>
>
> ------------------------------------------------------------------------
>
> /Volg Aquafin op Facebook <https://www.facebook.com/AquafinNV> | Twitter
> <https://twitter.com/aquafinnv> | YouTube
> <http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> |
> LinkedIN <http://www.linkedin.com/company/aquafin/products> /
>
> In het kader van de uitoefening van onze taken verzamelen we bij Aquafin
> persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van
> de betrokkenen zijn, kan je nalezen in onze privacy policy
> <https://www.aquafin.be/nl-be/privacy-policy>.
>
> P Denk aan het milieu. Druk deze mail niet onnodig af.
_______________________________________________
snmp-info-users mailing list
snm...@li...
https://lists.sourceforge.net/lists/listinfo/snmp-info-users
|
|
From: Jeroen v. I. <j.v...@ut...> - 2018-12-06 12:56:36
|
Hi Nick, The main SNMP::Info module needs /some/ way to get to the right device class. Generally, adding the vendor ID to the Layer2 and/or Layer3 mapping table is enough (especially if there's only one device class for that vendor). Regards, Jeroen van Ingen, Network Engineer University of Twente | Library, ICT Services & Archive (LISA) P.O.Box 217, 7500 AE Enschede, The Netherlands On 06-12-18 13:39, Nick Nauwelaerts wrote: > heya, > > i was wondering what step i missed in trying to add support for a new > vendor. > > more specifally, exinda devices - vendor id 21091. netdisco discovers > the device as enterprises.21091 > > netdisco-do show -d 10.40.254.16 -e vendor > > [25000] 2018-12-06 12:33:06 info App::Netdisco version 2.039033 loaded. > > [25000] 2018-12-06 12:33:06 info show: [10.40.254.16]/vendor started at > Thu Dec 6 13:33:06 2018 > > "enterprises.21091" > > netdisco-do show -d 10.40.254.16 -e serial > > [25022] 2018-12-06 12:33:32 info App::Netdisco version 2.039033 loaded. > > [25022] 2018-12-06 12:33:32 info show: [10.40.254.16]/serial started at > Thu Dec 6 13:33:32 2018 > > undef > > however, when using the explicit leaf: > > netdisco-do show -d 10.40.254.16 -e Layer2::Exinda::serial > > [25057] 2018-12-06 12:34:04 info App::Netdisco version 2.039033 loaded. > > [25057] 2018-12-06 12:34:04 info show: > [10.40.254.16]/Layer2::Exinda::serial started at Thu Dec 6 13:34:04 2018 > > "109836a9a4a9" > > netdisco-do show -d 10.40.254.16 -e Layer2::Exinda::vendor > > [25064] 2018-12-06 12:34:16 info App::Netdisco version 2.039033 loaded. > > [25064] 2018-12-06 12:34:16 info show: > [10.40.254.16]/Layer2::Exinda::vendor started at Thu Dec 6 13:34:16 2018 > > "Exinda" > > i tried deleted, expiring & rediscovering the device but to no avail. > > the main snmp::info has a list of fallbacks defined, but i was under the > impression that this was only needed when autodiscovery didnt work. > > thx > > // nick > > > ------------------------------------------------------------------------ > > /Volg Aquafin op Facebook <https://www.facebook.com/AquafinNV> | Twitter > <https://twitter.com/aquafinnv> | YouTube > <http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | > LinkedIN <http://www.linkedin.com/company/aquafin/products> / > > In het kader van de uitoefening van onze taken verzamelen we bij Aquafin > persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van > de betrokkenen zijn, kan je nalezen in onze privacy policy > <https://www.aquafin.be/nl-be/privacy-policy>. > > P Denk aan het milieu. Druk deze mail niet onnodig af. |
|
From: Nick N. <nic...@aq...> - 2018-12-06 12:40:05
|
heya, i was wondering what step i missed in trying to add support for a new vendor. more specifally, exinda devices - vendor id 21091. netdisco discovers the device as enterprises.21091 netdisco-do show -d 10.40.254.16 -e vendor [25000] 2018-12-06 12:33:06 info App::Netdisco version 2.039033 loaded. [25000] 2018-12-06 12:33:06 info show: [10.40.254.16]/vendor started at Thu Dec 6 13:33:06 2018 "enterprises.21091" netdisco-do show -d 10.40.254.16 -e serial [25022] 2018-12-06 12:33:32 info App::Netdisco version 2.039033 loaded. [25022] 2018-12-06 12:33:32 info show: [10.40.254.16]/serial started at Thu Dec 6 13:33:32 2018 undef however, when using the explicit leaf: netdisco-do show -d 10.40.254.16 -e Layer2::Exinda::serial [25057] 2018-12-06 12:34:04 info App::Netdisco version 2.039033 loaded. [25057] 2018-12-06 12:34:04 info show: [10.40.254.16]/Layer2::Exinda::serial started at Thu Dec 6 13:34:04 2018 "109836a9a4a9" netdisco-do show -d 10.40.254.16 -e Layer2::Exinda::vendor [25064] 2018-12-06 12:34:16 info App::Netdisco version 2.039033 loaded. [25064] 2018-12-06 12:34:16 info show: [10.40.254.16]/Layer2::Exinda::vendor started at Thu Dec 6 13:34:16 2018 "Exinda" i tried deleted, expiring & rediscovering the device but to no avail. the main snmp::info has a list of fallbacks defined, but i was under the impression that this was only needed when autodiscovery didnt work. thx // nick ________________________________ Volg Aquafin op Facebook<https://www.facebook.com/AquafinNV> | Twitter<https://twitter.com/aquafinnv> | YouTube<http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | LinkedIN<http://www.linkedin.com/company/aquafin/products> In het kader van de uitoefening van onze taken verzamelen we bij Aquafin persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van de betrokkenen zijn, kan je nalezen in onze privacy policy<https://www.aquafin.be/nl-be/privacy-policy>. P Denk aan het milieu. Druk deze mail niet onnodig af. |
|
From: Nick N. <nic...@aq...> - 2018-12-01 01:04:13
|
just the info i was after, thx. i'll see how far i get before getting stuck :) from easy to hard these are the issues i noticed & will have a try at fixing: 1) no mac address in device details 2) in reports->ssid inventory broadcast shows "no" for our ssids while we are in fact broadcasting them. might just not be possible to get that info from aerohive devices. 3) no clients show up in netdisco, neither in reports->access point client count or when looking at the device port overview (& have connected clients checked.). strange thing here is that the clients do show up when running netdisco-do show with the -e option, both when using generic leafs like cd11_mac or the specific aerohive ones like Layer2::Aerohive::cd11_mac. i guess this is be expected, so somewhere i must still be missing something. (i don't have store_wireless_clients defined in my deployment file, so it's using the defualt "1". verified with netdisco-do dumpconfig). ofcourse we have 0 access points from other vendors which makes tracing a working codepath that harder. thinking about this a bit more, it might not be a bad idea to store snmp output from a device when support is added, this could later be used for additional testing: * compare different os versions for feature support (like with aerohive serial support, which does not work in hiveos 6.5 but does work in 8.4) * when global data structures, workflow, whatever change in netdisco or snmp::info, regression checks could be made against actual snmp data from a real world device. https://github.com/netdisco/snmp-info/wiki/Simulating-Agents already explains how most of this could work. it's been added to my fifo queue, right after: items mentioned in this mail, trying to add exinda support, fixing oneaccess version reporting in newer os releases, adding redlion cellular router support, figuring out a way to update fortinet mibs & testing if my idea to represent hosted mpls networks actually works in practice (the idea is to use psuedo-devices to represent the mpls cloud & then linking each mpls connected device manually against the psuedo device representing the cloud. we have snmp read access with a limited but sufficient view on the provider cpe routers, but dont have access to any the routed data that might have been usefull with "App::Netdisco::Worker::Plugin::Discover::Neighbors::Routed"). since we'll be switching over 2000 sites in the next 2-3 years from legacy connections to ip connectivity it might be a valid scaling test. oh, and i also need to find time to finish up aerohive support for rancid (shameless plug: https://github.com/inphobia/rancid-aerohive-support ) at least i have big dreams, now let's see what i can delived on. :) // nick -----Original Message----- From: Jeroen van Ingen [mailto:j.v...@ut...] Sent: Wednesday, November 28, 2018 10:03 To: snm...@li... Subject: Re: [snmp-info] how does snmp::info find the mac address for a device? Hi, First of all, thank you for actively contributing! A few quick remarks: * Indeed, the Aerohive SNMP::Info class would be the correct place to rewrite this MAC address. Personally I wouldn't add a dependency on an external library to parse MAC addresses though; rather use a regex to strip all delimiters and then reformat to a colon-separated string. * Yes, it's a challenge to keep MIBs up to date and to maintain a collection that strives to be more complete than just bundling "latest release of $vendor". While Oliver already made large improvements to the process, it's still difficult to solve the aspect of "what to do when vendors are inconsistent, drop objects or make syntax errors". I'll do my best to look at the Exinda MIBs soon. Regards, Jeroen van Ingen, Network Engineer University of Twente | Library, ICT Services & Archive (LISA) P.O.Box 217, 7500 AE Enschede, The Netherlands On 28-11-18 00:51, Nick Nauwelaerts wrote: > coolness, once i'm done creating a few issues on github i'll get on it. > (done snmp::info #381 & netdisco #457 & #458) > > also, i'm trying to get basic support for exinda traffic shapers > working, any pointers are appreciated. code is here: > https://github.com/inphobia/snmp-info (against snmp::info 3.62. still > trying to figure out git's cloning, branching & such stuff. last rcs i > used was cvs...). > > also needs netdisco-mibs update > https://github.com/netdisco/netdisco-mibs/pull/55/commits/51c5a4a6ff837313dcb19f72de869c652667de42 > > the fortinet update in the same pull request is borked due to removing > eol device models. > > bonus question (from > https://github.com/netdisco/netdisco-mibs/pull/55#issuecomment-441240472): > > it seems like a challenge to maintain netdisco specific mibs entries > where deleted devices & such are still retained. i would like to suggest > a feature request where netdisco specific items could be split up into a > seperate file, so updates are more straightforward. it seems the > foundation for this is alrdy present since the update process diffs the > new & old indexes. perhaps this could be expanded so removed devices can > be merged back in at a later time. > > (or even unknown devices added, such as cisco C881G-4G-GA-K9 , > products.2057 which is missing even from the latest official cisco mibs. > filed a bug report but need to pass by my account manager to get it > added to the official mib...) > > take care & control. > > // nick > > *From:*Oliver Gorwits [mailto:ol...@cp...] > *Sent:* Tuesday, November 27, 2018 23:10 > *To:* snm...@li... > *Subject:* Re: [snmp-info] how does snmp::info find the mac address for > a device? > > Ni Nick > > Thanks for your questions! > > * can i overwrite this value or is this bad practice > > Yes, this is the purpose of the SNMP::Info device classes. You can use a > device class for Aerohive (Layer2::Aerohive?) to override the serial() > subroutine and try to find the serial for the various Aerohive devices. > > * since the format aerohive uses is none of the 4 formats netdisco > supports, to which format should i rewrite it to - or > does that not matter? > > We use the NetAddr::MAC module to parse and handle MAC addresses. It > will accept this format and then can return any other, such as > $mac->as_ieee(). > > * not all versions of hiveos seem to support this: hiveos 6.5r10 doesn't > support this oid, hiveos 8.x+ does. i guess this ain't no issue since > the same was true for device serial support ( > https://github.com/netdisco/snmp-info/pull/280 ) > > Exactly... this is the place to try different serial implementations. > > * is info::snmp::layer2::aerohive the correct place to overwrite a > layer3 value? i'm guessing yes, since that module also overwrites the > supported layers ( sub layers {return '00000111'; } ) > > Yes, I think so (if I understand the question correctly). > > regards, > > Oliver. > > On Tue, 27 Nov 2018 at 21:25, Nick Nauwelaerts > <nic...@aq... <mailto:nic...@aq...>> wrote: > > (crossposting to snmp::info & netdisco mailinglist, dunno if this is > frowned upon or not) > > on the overview page for a device netdisco shows a mac address. how > is this address found? > > for ios it seems to use: > > SNMP::Info::_global mac : IF-MIB::ifPhysAddress.1 : > .1.3.6.1.2.1.2.2.1.6.1 > > and on nx-os: > > SNMP::Info::_global mac : BRIDGE-MIB::dot1dBaseBridgeAddress.0 : > .1.3.6.1.2.1.17.1.1.0 > > command use to check was: > > netdisco-do show -II -d x.x.x.x -e mac > > i'm trying to get the aerohive snmp::info module a bit more in > shape, since that doesn't show a mac address. aerohive's management > appliance uses the mac address thats located at > .1.3.6.1.4.1.26928.1.3.2.0 for this. > > format is: > > .1.3.6.1.4.1.26928.1.3.2.0 = STRING: "c413:e244:a840" > > which ofcourse does not match any of the 4 formats supported: > > ieee -> ff:ff:ff:ff:ff:ff > > cisco -> ffff.ffff.ffff > > microsoft -> ff-ff-ff-ff-ff-ff > > sun -> like microsoft but seems to leave out leading zeros? (since > string parsing is even more fun when the format isn't fixed width :) ) > > if i read the snmp::info docs correctly i'm guessing i might come > from snmp::info::layer3.pm <http://layer3.pm>? ($l3->mac() -- > Returns root port mac address). > > so, bottom line: > > * can i overwrite this value or is this bad practice > > * since the format aerohive uses is none of the 4 formats netdisco > supports, to which format should i rewrite it to > - or does that not matter? > > * not all versions of hiveos seem to support this: hiveos 6.5r10 > doesn't support this oid, hiveos 8.x+ does. i guess this ain't no > issue since the same was true for device serial support ( > https://github.com/netdisco/snmp-info/pull/280 ) > > * is info::snmp::layer2::aerohive the correct place to overwrite a > layer3 value? i'm guessing yes, since that module also overwrites > the supported layers ( sub layers {return '00000111'; } ) > > thx for your time. > > // nick > > ------------------------------------------------------------------------ > > > /Volg Aquafin op Facebook <https://www.facebook.com/AquafinNV> | > Twitter <https://twitter.com/aquafinnv> | YouTube > <http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> > | LinkedIN <http://www.linkedin.com/company/aquafin/products> / > > In het kader van de uitoefening van onze taken verzamelen we bij > Aquafin persoonsgegevens. Hoe we omgaan met deze gegevens en wat de > rechten van de betrokkenen zijn, kan je nalezen in onze privacy > policy <https://www.aquafin.be/nl-be/privacy-policy>. > > PDenk aan het milieu. Druk deze mail niet onnodig af. > > _______________________________________________ > snmp-info-users mailing list > snm...@li... > <mailto:snm...@li...> > https://lists.sourceforge.net/lists/listinfo/snmp-info-users > _______________________________________________ snmp-info-users mailing list snm...@li... https://lists.sourceforge.net/lists/listinfo/snmp-info-users |
|
From: Jeroen v. I. <j.v...@ut...> - 2018-11-28 09:03:35
|
Hi, First of all, thank you for actively contributing! A few quick remarks: * Indeed, the Aerohive SNMP::Info class would be the correct place to rewrite this MAC address. Personally I wouldn't add a dependency on an external library to parse MAC addresses though; rather use a regex to strip all delimiters and then reformat to a colon-separated string. * Yes, it's a challenge to keep MIBs up to date and to maintain a collection that strives to be more complete than just bundling "latest release of $vendor". While Oliver already made large improvements to the process, it's still difficult to solve the aspect of "what to do when vendors are inconsistent, drop objects or make syntax errors". I'll do my best to look at the Exinda MIBs soon. Regards, Jeroen van Ingen, Network Engineer University of Twente | Library, ICT Services & Archive (LISA) P.O.Box 217, 7500 AE Enschede, The Netherlands On 28-11-18 00:51, Nick Nauwelaerts wrote: > coolness, once i'm done creating a few issues on github i'll get on it. > (done snmp::info #381 & netdisco #457 & #458) > > also, i'm trying to get basic support for exinda traffic shapers > working, any pointers are appreciated. code is here: > https://github.com/inphobia/snmp-info (against snmp::info 3.62. still > trying to figure out git's cloning, branching & such stuff. last rcs i > used was cvs...). > > also needs netdisco-mibs update > https://github.com/netdisco/netdisco-mibs/pull/55/commits/51c5a4a6ff837313dcb19f72de869c652667de42 > > the fortinet update in the same pull request is borked due to removing > eol device models. > > bonus question (from > https://github.com/netdisco/netdisco-mibs/pull/55#issuecomment-441240472): > > it seems like a challenge to maintain netdisco specific mibs entries > where deleted devices & such are still retained. i would like to suggest > a feature request where netdisco specific items could be split up into a > seperate file, so updates are more straightforward. it seems the > foundation for this is alrdy present since the update process diffs the > new & old indexes. perhaps this could be expanded so removed devices can > be merged back in at a later time. > > (or even unknown devices added, such as cisco C881G-4G-GA-K9 , > products.2057 which is missing even from the latest official cisco mibs. > filed a bug report but need to pass by my account manager to get it > added to the official mib...) > > take care & control. > > // nick > > *From:*Oliver Gorwits [mailto:ol...@cp...] > *Sent:* Tuesday, November 27, 2018 23:10 > *To:* snm...@li... > *Subject:* Re: [snmp-info] how does snmp::info find the mac address for > a device? > > Ni Nick > > Thanks for your questions! > > * can i overwrite this value or is this bad practice > > Yes, this is the purpose of the SNMP::Info device classes. You can use a > device class for Aerohive (Layer2::Aerohive?) to override the serial() > subroutine and try to find the serial for the various Aerohive devices. > > * since the format aerohive uses is none of the 4 formats netdisco > supports, to which format should i rewrite it to - or > does that not matter? > > We use the NetAddr::MAC module to parse and handle MAC addresses. It > will accept this format and then can return any other, such as > $mac->as_ieee(). > > * not all versions of hiveos seem to support this: hiveos 6.5r10 doesn't > support this oid, hiveos 8.x+ does. i guess this ain't no issue since > the same was true for device serial support ( > https://github.com/netdisco/snmp-info/pull/280 ) > > Exactly... this is the place to try different serial implementations. > > * is info::snmp::layer2::aerohive the correct place to overwrite a > layer3 value? i'm guessing yes, since that module also overwrites the > supported layers ( sub layers {return '00000111'; } ) > > Yes, I think so (if I understand the question correctly). > > regards, > > Oliver. > > On Tue, 27 Nov 2018 at 21:25, Nick Nauwelaerts > <nic...@aq... <mailto:nic...@aq...>> wrote: > > (crossposting to snmp::info & netdisco mailinglist, dunno if this is > frowned upon or not) > > on the overview page for a device netdisco shows a mac address. how > is this address found? > > for ios it seems to use: > > SNMP::Info::_global mac : IF-MIB::ifPhysAddress.1 : > .1.3.6.1.2.1.2.2.1.6.1 > > and on nx-os: > > SNMP::Info::_global mac : BRIDGE-MIB::dot1dBaseBridgeAddress.0 : > .1.3.6.1.2.1.17.1.1.0 > > command use to check was: > > netdisco-do show -II -d x.x.x.x -e mac > > i'm trying to get the aerohive snmp::info module a bit more in > shape, since that doesn't show a mac address. aerohive's management > appliance uses the mac address thats located at > .1.3.6.1.4.1.26928.1.3.2.0 for this. > > format is: > > .1.3.6.1.4.1.26928.1.3.2.0 = STRING: "c413:e244:a840" > > which ofcourse does not match any of the 4 formats supported: > > ieee -> ff:ff:ff:ff:ff:ff > > cisco -> ffff.ffff.ffff > > microsoft -> ff-ff-ff-ff-ff-ff > > sun -> like microsoft but seems to leave out leading zeros? (since > string parsing is even more fun when the format isn't fixed width :) ) > > if i read the snmp::info docs correctly i'm guessing i might come > from snmp::info::layer3.pm <http://layer3.pm>? ($l3->mac() -- > Returns root port mac address). > > so, bottom line: > > * can i overwrite this value or is this bad practice > > * since the format aerohive uses is none of the 4 formats netdisco > supports, to which format should i rewrite it to > - or does that not matter? > > * not all versions of hiveos seem to support this: hiveos 6.5r10 > doesn't support this oid, hiveos 8.x+ does. i guess this ain't no > issue since the same was true for device serial support ( > https://github.com/netdisco/snmp-info/pull/280 ) > > * is info::snmp::layer2::aerohive the correct place to overwrite a > layer3 value? i'm guessing yes, since that module also overwrites > the supported layers ( sub layers {return '00000111'; } ) > > thx for your time. > > // nick > > ------------------------------------------------------------------------ > > > /Volg Aquafin op Facebook <https://www.facebook.com/AquafinNV> | > Twitter <https://twitter.com/aquafinnv> | YouTube > <http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> > | LinkedIN <http://www.linkedin.com/company/aquafin/products> / > > In het kader van de uitoefening van onze taken verzamelen we bij > Aquafin persoonsgegevens. Hoe we omgaan met deze gegevens en wat de > rechten van de betrokkenen zijn, kan je nalezen in onze privacy > policy <https://www.aquafin.be/nl-be/privacy-policy>. > > PDenk aan het milieu. Druk deze mail niet onnodig af. > > _______________________________________________ > snmp-info-users mailing list > snm...@li... > <mailto:snm...@li...> > https://lists.sourceforge.net/lists/listinfo/snmp-info-users > |
|
From: Nick N. <nic...@aq...> - 2018-11-27 23:51:28
|
coolness, once i'm done creating a few issues on github i'll get on it. (done snmp::info #381 & netdisco #457 & #458) also, i'm trying to get basic support for exinda traffic shapers working, any pointers are appreciated. code is here: https://github.com/inphobia/snmp-info (against snmp::info 3.62. still trying to figure out git's cloning, branching & such stuff. last rcs i used was cvs...). also needs netdisco-mibs update https://github.com/netdisco/netdisco-mibs/pull/55/commits/51c5a4a6ff837313dcb19f72de869c652667de42 the fortinet update in the same pull request is borked due to removing eol device models. bonus question (from https://github.com/netdisco/netdisco-mibs/pull/55#issuecomment-441240472): it seems like a challenge to maintain netdisco specific mibs entries where deleted devices & such are still retained. i would like to suggest a feature request where netdisco specific items could be split up into a seperate file, so updates are more straightforward. it seems the foundation for this is alrdy present since the update process diffs the new & old indexes. perhaps this could be expanded so removed devices can be merged back in at a later time. (or even unknown devices added, such as cisco C881G-4G-GA-K9 , products.2057 which is missing even from the latest official cisco mibs. filed a bug report but need to pass by my account manager to get it added to the official mib...) take care & control. // nick From: Oliver Gorwits [mailto:ol...@cp...] Sent: Tuesday, November 27, 2018 23:10 To: snm...@li... Subject: Re: [snmp-info] how does snmp::info find the mac address for a device? Ni Nick Thanks for your questions! * can i overwrite this value or is this bad practice Yes, this is the purpose of the SNMP::Info device classes. You can use a device class for Aerohive (Layer2::Aerohive?) to override the serial() subroutine and try to find the serial for the various Aerohive devices. * since the format aerohive uses is none of the 4 formats netdisco supports, to which format should i rewrite it to - or does that not matter? We use the NetAddr::MAC module to parse and handle MAC addresses. It will accept this format and then can return any other, such as $mac->as_ieee(). * not all versions of hiveos seem to support this: hiveos 6.5r10 doesn't support this oid, hiveos 8.x+ does. i guess this ain't no issue since the same was true for device serial support ( https://github.com/netdisco/snmp-info/pull/280 ) Exactly... this is the place to try different serial implementations. * is info::snmp::layer2::aerohive the correct place to overwrite a layer3 value? i'm guessing yes, since that module also overwrites the supported layers ( sub layers {return '00000111'; } ) Yes, I think so (if I understand the question correctly). regards, Oliver. On Tue, 27 Nov 2018 at 21:25, Nick Nauwelaerts <nic...@aq...<mailto:nic...@aq...>> wrote: (crossposting to snmp::info & netdisco mailinglist, dunno if this is frowned upon or not) on the overview page for a device netdisco shows a mac address. how is this address found? for ios it seems to use: SNMP::Info::_global mac : IF-MIB::ifPhysAddress.1 : .1.3.6.1.2.1.2.2.1.6.1 and on nx-os: SNMP::Info::_global mac : BRIDGE-MIB::dot1dBaseBridgeAddress.0 : .1.3.6.1.2.1.17.1.1.0 command use to check was: netdisco-do show -II -d x.x.x.x -e mac i'm trying to get the aerohive snmp::info module a bit more in shape, since that doesn't show a mac address. aerohive's management appliance uses the mac address thats located at .1.3.6.1.4.1.26928.1.3.2.0 for this. format is: .1.3.6.1.4.1.26928.1.3.2.0 = STRING: "c413:e244:a840" which ofcourse does not match any of the 4 formats supported: ieee -> ff:ff:ff:ff:ff:ff cisco -> ffff.ffff.ffff microsoft -> ff-ff-ff-ff-ff-ff sun -> like microsoft but seems to leave out leading zeros? (since string parsing is even more fun when the format isn't fixed width :) ) if i read the snmp::info docs correctly i'm guessing i might come from snmp::info::layer3.pm<http://layer3.pm>? ($l3->mac() -- Returns root port mac address). so, bottom line: * can i overwrite this value or is this bad practice * since the format aerohive uses is none of the 4 formats netdisco supports, to which format should i rewrite it to - or does that not matter? * not all versions of hiveos seem to support this: hiveos 6.5r10 doesn't support this oid, hiveos 8.x+ does. i guess this ain't no issue since the same was true for device serial support ( https://github.com/netdisco/snmp-info/pull/280 ) * is info::snmp::layer2::aerohive the correct place to overwrite a layer3 value? i'm guessing yes, since that module also overwrites the supported layers ( sub layers {return '00000111'; } ) thx for your time. // nick ________________________________ Volg Aquafin op Facebook<https://www.facebook.com/AquafinNV> | Twitter<https://twitter.com/aquafinnv> | YouTube<http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | LinkedIN<http://www.linkedin.com/company/aquafin/products> In het kader van de uitoefening van onze taken verzamelen we bij Aquafin persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van de betrokkenen zijn, kan je nalezen in onze privacy policy<https://www.aquafin.be/nl-be/privacy-policy>. P Denk aan het milieu. Druk deze mail niet onnodig af. _______________________________________________ snmp-info-users mailing list snm...@li...<mailto:snm...@li...> https://lists.sourceforge.net/lists/listinfo/snmp-info-users |
|
From: Oliver G. <ol...@cp...> - 2018-11-27 22:10:11
|
Ni Nick Thanks for your questions! * can i overwrite this value or is this bad practice Yes, this is the purpose of the SNMP::Info device classes. You can use a device class for Aerohive (Layer2::Aerohive?) to override the serial() subroutine and try to find the serial for the various Aerohive devices. * since the format aerohive uses is none of the 4 formats netdisco supports, to which format should i rewrite it to - or does that not matter? We use the NetAddr::MAC module to parse and handle MAC addresses. It will accept this format and then can return any other, such as $mac->as_ieee(). * not all versions of hiveos seem to support this: hiveos 6.5r10 doesn't support this oid, hiveos 8.x+ does. i guess this ain't no issue since the same was true for device serial support ( https://github.com/netdisco/snmp-info/pull/280 ) Exactly... this is the place to try different serial implementations. * is info::snmp::layer2::aerohive the correct place to overwrite a layer3 value? i'm guessing yes, since that module also overwrites the supported layers ( sub layers {return '00000111'; } ) Yes, I think so (if I understand the question correctly). regards, Oliver. On Tue, 27 Nov 2018 at 21:25, Nick Nauwelaerts <nic...@aq...> wrote: > (crossposting to snmp::info & netdisco mailinglist, dunno if this is > frowned upon or not) > > > > on the overview page for a device netdisco shows a mac address. how is > this address found? > > > > for ios it seems to use: > > SNMP::Info::_global mac : IF-MIB::ifPhysAddress.1 : .1.3.6.1.2.1.2.2.1.6.1 > > > > and on nx-os: > > SNMP::Info::_global mac : BRIDGE-MIB::dot1dBaseBridgeAddress.0 : > .1.3.6.1.2.1.17.1.1.0 > > > > command use to check was: > > netdisco-do show -II -d x.x.x.x -e mac > > > > > > i'm trying to get the aerohive snmp::info module a bit more in shape, > since that doesn't show a mac address. aerohive's management appliance uses > the mac address thats located at .1.3.6.1.4.1.26928.1.3.2.0 for this. > > format is: > > .1.3.6.1.4.1.26928.1.3.2.0 = STRING: "c413:e244:a840" > > > > which ofcourse does not match any of the 4 formats supported: > > ieee -> ff:ff:ff:ff:ff:ff > > cisco -> ffff.ffff.ffff > > microsoft -> ff-ff-ff-ff-ff-ff > > sun -> like microsoft but seems to leave out leading zeros? (since string > parsing is even more fun when the format isn't fixed width :) ) > > > > > > > > if i read the snmp::info docs correctly i'm guessing i might come from > snmp::info::layer3.pm? ($l3->mac() -- Returns root port mac address). > > > > > > so, bottom line: > > * can i overwrite this value or is this bad practice > > * since the format aerohive uses is none of the 4 formats netdisco > supports, to which format should i rewrite it to - or > does that not matter? > > * not all versions of hiveos seem to support this: hiveos 6.5r10 doesn't > support this oid, hiveos 8.x+ does. i guess this ain't no issue since the > same was true for device serial support ( > https://github.com/netdisco/snmp-info/pull/280 ) > > * is info::snmp::layer2::aerohive the correct place to overwrite a layer3 > value? i'm guessing yes, since that module also overwrites the supported > layers ( sub layers {return '00000111'; } ) > > > > thx for your time. > > > > // nick > > > > ------------------------------ > > *Volg Aquafin op Facebook <https://www.facebook.com/AquafinNV> | Twitter > <https://twitter.com/aquafinnv> | YouTube > <http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | > LinkedIN <http://www.linkedin.com/company/aquafin/products> * > > In het kader van de uitoefening van onze taken verzamelen we bij Aquafin > persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van de > betrokkenen zijn, kan je nalezen in onze privacy policy > <https://www.aquafin.be/nl-be/privacy-policy>. > > P Denk aan het milieu. Druk deze mail niet onnodig af. > _______________________________________________ > snmp-info-users mailing list > snm...@li... > https://lists.sourceforge.net/lists/listinfo/snmp-info-users > |
|
From: Nick N. <nic...@aq...> - 2018-11-27 21:24:39
|
(crossposting to snmp::info & netdisco mailinglist, dunno if this is frowned upon or not) on the overview page for a device netdisco shows a mac address. how is this address found? for ios it seems to use: SNMP::Info::_global mac : IF-MIB::ifPhysAddress.1 : .1.3.6.1.2.1.2.2.1.6.1 and on nx-os: SNMP::Info::_global mac : BRIDGE-MIB::dot1dBaseBridgeAddress.0 : .1.3.6.1.2.1.17.1.1.0 command use to check was: netdisco-do show -II -d x.x.x.x -e mac i'm trying to get the aerohive snmp::info module a bit more in shape, since that doesn't show a mac address. aerohive's management appliance uses the mac address thats located at .1.3.6.1.4.1.26928.1.3.2.0 for this. format is: .1.3.6.1.4.1.26928.1.3.2.0 = STRING: "c413:e244:a840" which ofcourse does not match any of the 4 formats supported: ieee -> ff:ff:ff:ff:ff:ff cisco -> ffff.ffff.ffff microsoft -> ff-ff-ff-ff-ff-ff sun -> like microsoft but seems to leave out leading zeros? (since string parsing is even more fun when the format isn't fixed width :) ) if i read the snmp::info docs correctly i'm guessing i might come from snmp::info::layer3.pm? ($l3->mac() -- Returns root port mac address). so, bottom line: * can i overwrite this value or is this bad practice * since the format aerohive uses is none of the 4 formats netdisco supports, to which format should i rewrite it to - or does that not matter? * not all versions of hiveos seem to support this: hiveos 6.5r10 doesn't support this oid, hiveos 8.x+ does. i guess this ain't no issue since the same was true for device serial support ( https://github.com/netdisco/snmp-info/pull/280 ) * is info::snmp::layer2::aerohive the correct place to overwrite a layer3 value? i'm guessing yes, since that module also overwrites the supported layers ( sub layers {return '00000111'; } ) thx for your time. // nick ________________________________ Volg Aquafin op Facebook<https://www.facebook.com/AquafinNV> | Twitter<https://twitter.com/aquafinnv> | YouTube<http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | LinkedIN<http://www.linkedin.com/company/aquafin/products> In het kader van de uitoefening van onze taken verzamelen we bij Aquafin persoonsgegevens. Hoe we omgaan met deze gegevens en wat de rechten van de betrokkenen zijn, kan je nalezen in onze privacy policy<https://www.aquafin.be/nl-be/privacy-policy>. P Denk aan het milieu. Druk deze mail niet onnodig af. |
|
From: Oliver G. <ol...@cp...> - 2018-06-05 21:22:29
|
Hi Mark On 2018-06-04 16:52, Mark Tinberg via snmp-info-users wrote: > In the interim maybe I can peruse the Netdisco source to see how it > uses SNMP::Info Here's where to start: https://github.com/netdisco/netdisco/blob/master/lib/App/Netdisco/Transport/SNMP.pm#L118 And the IgnoreNetSNMPConf setting might be your friend to add tighter control over the configuration. However the SNMP::Info docs themselves are using almost the same code. You can also grab the net-snmp session (SNMP::Session instance) after allowing SNMP::Info to connect, as it lives in $info->session(). Good luck, regards, oliver. > , which seems a very useful library that can get rid of > thousands of lines of procedural scripts with hardcoded OIDs that > require modification for every minor difference in devices. > > Right now I'd be happy to cache the NetSNMP initialization so I'm not > creating it anew every iteration of the loop > > On Tue, 2018-05-29 at 20:57 +0100, Oliver Gorwits wrote: >> >> Have you considered using Netdisco application for your inventory? > > >> On 2018-05-25 23:05, Mark Tinberg via snmp-info-users wrote: >> > [...snip...] I create a new SNMP::Info >> > object to connect to a host it takes 3-4s for SNMP::initMib >> > [...snip...] |
|
From: Mark T. <mar...@wi...> - 2018-06-04 15:52:53
|
I am considering it, the in-house application that I maintain provides highly delegated access to make VLAN changes on access switch ports for hundreds of distinct IT teams, something that a quick skim of the Netdisco FAQ suggests it is capable of doing, but right now I have existing process and procedure to maintain and can't change the world right now. In the interim maybe I can peruse the Netdisco source to see how it uses SNMP::Info, which seems a very useful library that can get rid of thousands of lines of procedural scripts with hardcoded OIDs that require modification for every minor difference in devices. Right now I'd be happy to cache the NetSNMP initialization so I'm not creating it anew every iteration of the loop On Tue, 2018-05-29 at 20:57 +0100, Oliver Gorwits wrote: > > Have you considered using Netdisco application for your inventory? > On 2018-05-25 23:05, Mark Tinberg via snmp-info-users wrote: > > [...snip...] I create a new SNMP::Info > > object to connect to a host it takes 3-4s for SNMP::initMib > > [...snip...] -- Mark Tinberg <mar...@wi...> University of Wisconsin-Madison Division of Information Technology-Network Services |
|
From: Oliver G. <ol...@cp...> - 2018-05-29 19:57:51
|
Hi Mark, Have you considered using Netdisco application for your inventory? It uses SNMP::Info and while I don't know whether it will be faster, it does at least use it in a way which works for most users in an efficient manner. http://netdisco.org/ regards, oliver. On 2018-05-25 23:05, Mark Tinberg via snmp-info-users wrote: > I'm not sure if I'm "doing it wrong" but when I create a new SNMP::Info > object to connect to a host it takes 3-4s for SNMP::initMib to process > the MIB files, using snmp.conf and only the rfc and cisco directories > in the mibdir path. Trying to loop over a list of devices and get > inventory information takes hours. Is that expected behavior? I can > parallelize by invoking my utility once per host using xargs but that > drives up load and maxes out the CPUs on my NMS system. > > There must be a more efficient way to pull data from multiple devices > that I'm just missing. |
|
From: Mark T. <mar...@wi...> - 2018-05-25 22:05:48
|
I'm not sure if I'm "doing it wrong" but when I create a new SNMP::Info object to connect to a host it takes 3-4s for SNMP::initMib to process the MIB files, using snmp.conf and only the rfc and cisco directories in the mibdir path. Trying to loop over a list of devices and get inventory information takes hours. Is that expected behavior? I can parallelize by invoking my utility once per host using xargs but that drives up load and maxes out the CPUs on my NMS system. There must be a more efficient way to pull data from multiple devices that I'm just missing. -- Mark Tinberg <mar...@wi...> University of Wisconsin-Madison Division of Information Technology-Network Services |
|
From: Karel V. <k.v...@sk...> - 2017-04-12 10:30:07
|
Hi, I recently came back to issue resolving TP-Link devices with NetDisco. Half a year back Jeroen van Ingen helped processing TP-Link MIBs adding them to git package of netdisco-mibs, but reminded I need to extend SNMP::Info for a new class for TP-Link switches. I'm not familiar with Perl nor internal functionality of SNMP::Info so I wanted to ask if anyone could kindly add TP-Link class to SNMP::Info. I have read the guidelines but I don't get the idea :/. Thanks for any help. Karel Vychodsky |
45 messages has been excluded from this view by a project administrator.