search

netdisco / snmp-info

Other
36 stars 31 forks source link

DLink OID sysServices ( .1.3.6.1.2.1.1.7) = "01001000" #401

Closed atretyakov closed 2 years ago

atretyakov commented 5 years ago

Hello, some d-link switches -DES-1210-28/ME, DGS-1210-28/ME etc indicates OID sysServices ( .1.3.6.1.2.1.1.7) = "01001000".

~/bin/netdisco-do show -d des1210-28me-51-3 -e layers [137115] 2019-01-28 08:53:33 info App::Netdisco version 2.040003 loaded. [137115] 2019-01-28 08:53:33 info show: [10.0.10.44]/layers started at Mon Jan 28 11:53:33 2019 "01001000"

Therefore, netdisco does not collect level 2 and 3 information . What to do ?

inphobia commented 5 years ago

is this a new installation or did it work on previous versions of netdisco. also, snmp::info & netdisco versions would be usefull.

the most common solution for this is to overwrite the layers() in the snmp::info module, but this can cause regressions for other models using the same module.

atretyakov commented 5 years ago

thanks for the answer. I have a new installation, netdisco v. 2.040003, SNMP :: Info V. 3.64

Could you please clarify exactly what editing is required and which files in the snmp :: info module? I'm afraid to do something wrong with my intervention.

respect, Alexander Tretyakov

inphobia commented 5 years ago

well, overwriting layers() might have consequences for other devices using that class so we can't do it blindly.

first we need to know what snmp::info class your device is using; the easiest way to find that out is: netdisco-do show -d <ipaddr> -e class

atretyakov commented 5 years ago

[netdisco@v-nmon root]$ ~/bin/netdisco-do show -d des1210-28me-51-3 -e class [154105] 2019-01-31 11:53:44 info App::Netdisco version 2.040003 loaded. [154105] 2019-01-31 11:53:44 info show: [10.0.10.44]/class started at Thu Jan 31 14:53:44 2019 "SNMP::Info::Layer3::DLink"

respect, Alexander Tretyakov

inphobia commented 5 years ago

then you can try to add a layers function to SNMP::Info::Layer3::DLink.pm https://github.com/netdisco/snmp-info/blob/master/lib/SNMP/Info/Layer3/DLink.pm

as an example on how to do it: https://github.com/netdisco/snmp-info/blob/master/lib/SNMP/Info/Layer2/Exinda.pm#L68

with value '00000110' as the return value.

Info.pm might also need changes if you noticed if the device gets discovered correctly half of the time (so every time you press discover; one time it will work, the next one it will return the old info).

please keep in mind that this is for testing purposes, if this fixes your device we'll need to have a look at how to incorporate this without breaking other dlink devices.

atretyakov commented 5 years ago

Thanks! It works. Macsuck and arpnip run correctly. Negative events you warn about not yet seen. I will observe the process and tell you the results.

very grateful, you really helped me.

Alexander Tretyakov.

inphobia commented 5 years ago

the problem we have is that while this might fix your devices but could break others.

i don't know how many dlink devices you have, but if at all possible, could you test this on all of them for a few days and make a list of devicetypes and os revisions they're using? a netdisco-do show -d <ip> -e ::layers off them would also be usefull. don't forget to use ::layers , that way we use the base class and don't include the override you just added.

that might give us better insight in the risk changing this.

thx!

atretyakov commented 5 years ago

Here are my D-link switches.

Those having layers = "01001000" were not polled before the file SNMP::Info::Layer3::DLink.pm was changed.

type firmware ver. layers
DES-1210-28/B1 3.12.B032 "01001000"
DES-1210-26/ME/B1 6.10.B050 "01001000"
DES-1210-28/ME/B2 6.10.B052 "01001000"
DES-1210-28/ME/B3 10.04.B036 "01001000"
DGS-1210-28/ME/A1 6.13.B036 "01001000"

Others with layers = "00000011" were normally polled before the file was changed.

DES-3526 5.01.B60 "00000011"
DGS-1510-28 1.30.007 "00000011"
DGS-1510-28XS/ME 2.00.B014 "00000011"
DES-3010G/A3 4.30.B21 "00000011"
DES-3028/1A1G 1.00-B32 "00000011"
DES-3028/A2 2.00.B27 "00000011"

the last switch did not respond to the request for layers at all

DES-1210-28/A1 5.10.B046 ---------- [netdisco@v-nmon root]$ ~/bin/netdisco-do show -e ::layers -d des1210-28-op-3 [160634] 2019-02-01 05:29:00 info App::Netdisco version 2.040003 loaded. [160634] 2019-02-01 05:29:00 info show: error - Don't know device: 10.0.10.31

inphobia commented 5 years ago

Others with layers = "00000011" were normally polled before the file was changed.

and those still behave the same after the change?

if possible, can you delete 1 of them & rediscover it? i want to make sure i don't introduce any regressions.

the last switch did not respond to the request for layers at all

DES-1210-28/A1 5.10.B046 ---------- [netdisco@v-nmon root]$ ~/bin/netdisco-do show -e ::layers -d des1210-28-op-3 [160634] 2019-02-01 05:29:00 info App::Netdisco version 2.040003 loaded. [160634] 2019-02-01 05:29:00 info show: error - Don't know device: 10.0.10.31

this means netdisco never did a succesful discover of the device as far as i can tell. i would first check if the snmp community is known & there is no connectivty issue (in other words, i would try an snmpwalk from the netdisco server first)

atretyakov commented 5 years ago

and those still behave the same after the change?

yes those behave the same. I deleted and then rediscover a DES-3028, it seemingly remained the same.

this means netdisco never did a succesful discover of the device

you're right it was off

inphobia commented 5 years ago

i had a quick look at the dlink website & it seems they have both layer2 and layer3 switches. i'm not quite sure what the best way to proceed is. overwriting layers() will impact everything that uses the class, also the layer2 only devices.

perhaps the best way to to check for layers, if they report layers 2 and/or 3 just accept what the device sends us. if they report layers 4+7 like the example overwrite it to layers 2+3.

the deviced you listed in the second table who are reporting layers 1+2, do any of those also have layer3 features, even if it's just static routing?

inphobia commented 5 years ago

@jeneric & @JeroenvIS what do you think is the most elegant way to solve this? some devices in the dlink class report their layers correctly, some dont. so a layers() override is needed in some cases.

with the info i have right now it seems that when the device reports it does layer 4+7, layers 2+3 should be added too

thx

atretyakov commented 5 years ago

All the devices we are talking about support layer3: ARP, ip ACL, IP-MAC-Port Binding, etc and higher level protocols for management purposes http(s), ssh, telnet. It is not clear for what reason some of them have sysServices = 01001000, and the other have 00000011.

the device reports it does layer 4+7, layers 2+3 should be added too

I think the same.

inphobia commented 5 years ago

should be an snmp::info issue imo.

@ollyg , @JeroenvIS , @jeneric - can you migrate this plz?

7ElviN7 commented 5 years ago

Hi! Can you say, what I need to do to collect right information? I can't understand.....(((( This problem with DGS-1100-10/ME, DGS-1100-06/ME

inphobia commented 5 years ago

bottom line, we need to update the snmp::info module to overwrite certains parts of what the dlink devices return.

it would be helpful however to have some snmp dumps of devices that are not working, the procedure is described here: https://github.com/netdisco/snmp-info/wiki/Simulating-Agents#21-snmpsim--snmprec-version

7ElviN7 commented 5 years ago

Thank's for your answer. If you need, i can give you remote access to the switch DGS1106. I'm trying to do your instructions.

inphobia commented 5 years ago

Thank's for your answer. If you need, i can give you remote access to the switch DGS1106. I'm trying to do your instructions.

well, a dump would be usefull to get this resolved a lot faster and easier. what part of the procedure are you stuck on?

7ElviN7 commented 4 years ago

Thank's for your answer. If you need, i can give you remote access to the switch DGS1106. I'm trying to do your instructions.

well, a dump would be usefull to get this resolved a lot faster and easier. what part of the procedure are you stuck on?

Hi! maybe I'm doing something wrong, but i'm getting error

(snmpsim) root@VL:~/python-env/snmpsimdata# datafile.py --source-record-type=snmpwalk --input-file=/home/elvin/python-env/python-env/snmpwalk36_246.out > dgs1106.snmprec

Input file #0, processing records from the beginning till the end

ERROR: broken record <0C 7B 0D F8

: broken record <0C 7B 0D F8

(snmpsim) root@VL:~/python-env/snmpsimdata# snmpstatus -v2c -c 10.11.36.246.snmprec 127.0.0.1:1161 Unlinked OID in IPATM-IPMC-MIB: marsMIB ::= { mib-2 57 } Undefined identifier: mib-2 near line 18 of /usr/share/mibs/ietf/IPATM-IPMC-MIB Bad operator (INTEGER): At line 73 in /usr/share/mibs/ietf/SNMPv2-PDU Expected "::=" (RFC5644): At line 493 in /usr/share/mibs/iana/IANA-IPPM-METRICS-REGISTRY-MIB Expected "{" (EOF): At line 651 in /usr/share/mibs/iana/IANA-IPPM-METRICS-REGISTRY-MIB Bad object identifier: At line 651 in /usr/share/mibs/iana/IANA-IPPM-METRICS-REGISTRY-MIB Bad parse of OBJECT-IDENTITY: At line 651 in /usr/share/mibs/iana/IANA-IPPM-METRICS-REGISTRY-MIB Timeout: No Response from 127.0.0.1:1161

inphobia commented 4 years ago

at first glance it seems that you're using a file generated with snmpwalk & snmpsim found some unexpected data. snmpwalk output needs extra work to load in snmpsim. a quickstart for that is here: https://github.com/netdisco/snmp-info/wiki/Simulating-Agents#4-fix-up-the-snmpwalk

but i never got it to work 100% correct with that method.

i really recommend using snmprec.py to generate your input file instead of snmpwalk: snmprec.py --agent-udpv4-endpoint={device} --start-object=1.0 --output-file={device}.snmprec --protocol-version=2c --community={community}

snmprec is included in the snmpsim package.

also, did you start snmpsimd? that part seems to be missing from your post (https://github.com/netdisco/snmp-info/wiki/Simulating-Agents#6-start-the-simulator). ofcourse for that you do need to get a valid snmprec file first.

side note: i think you need to drop the "snmprec" from your community: snmpstatus -v 2c -c 10.11.36.246 127.0.0.1:1161

a quickstart guide & full manual for snmpsim can be found here: http://snmplabs.com/snmpsim/quickstart.html#

JeroenvIS commented 3 years ago

I'd be fine with a small change in SNMP::Info::Layer3::DLink to always report layers 2 & 3; I've worked with DLink devices for a while and never saw a model that couldn't do at least some basic L2 & L3.

A more elegant approach than "always report these layers" could be to actually test a common L2 method (eg dot1dBaseNumPorts) and return L2 capability if that method is implemented.

ollyg commented 2 years ago

added fix in commit 0e75c44c (needs testing)

this is in line with first easier suggestion by @JeroenvIS to simply always report 2+3