Debian 10.3 error updadevicing one device
nicolatron opened this issue · comments
Hello,
I want to create a module to parse F5 LTM ARP (and maybe FWT) information. I wanted to create a develop machine to do it. I installed the EPIC plugin for eclipse, and debugger is working fine with Netdot code, so that's a big thumbs up for me (I'm not proficient with perl so having an IDE debugger will potentially save me time along the way).
So... I'm trying Netdot in debian 10. I tried it on 3 different debian 10 machines, with different pre-installed packges, and found different problems in the installation process, but in general problems were easily solvable, some packages have been renamed (from the names found in the make apt-install, like mariadb-server), many of the perl packages could be easily installed from cpan or the corresponding lib*-perl apt packages , the most problematic was Net::DNS::ZoneFile::Fast, as it seems to not exists anymore on cpan (or maybe I'm searching it wrong), on one of the systems I installed it from a jessie .deb and it (seems) to work fine as the package from Buster repos (libnet-dns-zonefile-fast-perl) did not seem to fullfill the make testdeps requirements.
I've installed net-snmp 5.8 from sources and latest netdisco-mibs.
So now i have a "main" Debian 10, Netdot developing system, and I've been adding a number of devices (cisco 4500, h3c, hp, cisco asa, netscreen), everything is going ok. BTW I already have a Netscreen.pm ready for prime to get arp tables via CLI (Only working and tested with ipv4 I'm afraid), I'll do a pull request with it.
But I'm now facing a problem with a cisco 6500 VSS, it is giving an error when trying to add it.
Final error is:
ERROR: Error while inserting DeviceModule: Can't insert new DeviceModule: DBD::mysql::st execute failed: Duplicate entry '13-0' for key 'devicemodule1'[...]
But I think the root cause, is more related with previous errors:
SNMP::Info::_load_attr: BULKWALK Timeout at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_load_attr: BULKWALK Timeout at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_load_attr: BULKWALK Timeout at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_load_attr: BULKWALK Timeout at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_load_attr: BULKWALK Timeout at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_global(lldp_sys_cap) NOSUCHOBJECT at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_load_attr: BULKWALK Timeout at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_load_attr: BULKWALK Timeout at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 620.
SNMP::Info::_global(serial1) NOSUCHOBJECT at /usr/local/share/perl/5.28.1/SNMP/Info/CiscoStack.pm line 122.
SNMP::Info::_global(serial2) NOSUCHOBJECT at /usr/local/share/perl/5.28.1/SNMP/Info/CiscoStack.pm line 123.
Use of uninitialized value in int at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 855.
This last line repeats 425 times. Wich is exactly the number of modules that my production Netdot discovers for that same device.
Searching a bit for that kind of BULKWALK Timeout errors, lead me to netdisco errors, where people were apparently missing required mibs. So I did copy over the mibs on the production machine, pointed Netdot to that mibs, but error is the same. Any idea is appreciated.
Full output of updatedevices.pl -d is attached
updatedevice_vss_error.txt
.
Forget about this.
For this covid stuff I was connecting my dev system from home, and directing snmp queries through a gre tunnel (so I don't have to open permissions on devices from my vpn ip), the error is related to the gre tunnel, and packet fragmentation. Too big snmp queries seems to fail.
Interestingly if i do the same query using snmpwalk (for example .1.3.6.1.2.1.47.1.1.1.1.2 takes 33 seconds on this device) it works, doing the "same" (I guess it does t hat and more things) from updatedevices.pl fails.
Anyway I repeated this tests with latest git version, but from a computer not using gre tunnel or vpn and it works.
BTW lowering the MTU to 1388 on both ends of the gre tunnel (they didn't even have the same MTU at first) fixed the problems from the dev system.