Error oid not increasing

Python SNMP library. Contribute to etingof/pysnmp development by creating an account on GitHub.

Permalink

Cannot retrieve contributors at this time

Dealing with the «OID not increasing» error

  1. I’m walking a particular Agent with the nextCmd() or bulkCmd()
    functions. It works for some OIDs, but invariably fails at certain
    OID with the OID not increasing error. What does it mean and
    how do I fix that?
  1. The Agent you are talking to seems to be broken. The
    OID not increasing message means that in the course of fetching
    OIDs from the Agent, Manager receives an OID that is not greater than those
    passed in request.
    Due to the nature of GETNEXT/GETBULK algorithm, passing the same or
    lesser OID to Manager would result in fetching the same set of OIDs over
    and over again effectively creating an infinite loop between Manager
    and Agent so they may never reach the end of MIB. To prevent this the
    Manager tries to intervene and prevent such loop from happening.

    If you have to work with a broken Agent and can terminate the
    GETNEXT/GETBULK command at some point, you can pass the
    ignoreNonIncreasingOid=True keyword parameter to the nextCmd() or bulkCmd()
    to disable OID verification at the Manager side.

for (errorIndication,
     errorStatus,
     errorIndex,
     varBinds) in nextCmd(SnmpEngine(),
                          CommunityData('public'),
                          UdpTransportTarget(('demo.snmplabs.com', 161)),
                          ContextData(),
                          ObjectType(ObjectIdentity('1.3.6')),
                          ignoreNonIncreasingOid=True):

    if errorIndication:
        print(errorIndication)
        break
    elif errorStatus:
        print('%s at %s' % (errorStatus.prettyPrint(),
                            errorIndex and varBinds[int(errorIndex) - 1][0] or '?'))
        break
    else:
        for varBind in varBinds:
            print(' = '.join([x.prettyPrint() for x in varBind])

Автор Сообщение

Заголовок сообщения: DES-2108: SNMP Error: OID not increasing

СообщениеДобавлено: Пн дек 24, 2007 12:05 

Не в сети



Зарегистрирован: Пн апр 02, 2007 19:03
Сообщений: 9

Здравствуйте.

Спасибо за так быстро предоставленную прошивку. :)

Новая проблема. Имеется:

Product Name DES-2108 (железный)

Firmware Version 3.00.23

Protocol Version 2.001.002

Пытаюсь получить список маков по SNMP

$ snmpwalk -v 1 -c public ip-addr IP-MIB::ipNetToMediaIfIndex

IP-MIB::ipNetToMediaIfIndex.604.172.20.1.33 = INTEGER: 604

IP-MIB::ipNetToMediaIfIndex.604.172.20.1.3 = INTEGER: 604

Error: OID not increasing: IP-MIB::ipNetToMediaIfIndex.604.172.20.1.33

>= IP-MIB::ipNetToMediaIfIndex.604.172.20.1.3

И всё.

Можно как-нибудь исправить?

Спасибо

Вернуться наверх

Профиль  

Bigarov Ruslan

Заголовок сообщения: Re: DES-2108: SNMP Error: OID not increasing

СообщениеДобавлено: Пн дек 24, 2007 12:39 



Зарегистрирован: Пт янв 21, 2005 11:52
Сообщений: 11211
Откуда: D-Link, Moscow

snmpwalk -v2c -c public 192.168.0.1 1.3.6.1.2.1.17.4.3.1.1

_________________
С уважением,

Бигаров Руслан.

Вернуться наверх

Профиль  

yuray10

Заголовок сообщения: Re: DES-2108: SNMP Error: OID not increasing

СообщениеДобавлено: Пн дек 24, 2007 13:06 

Не в сети



Зарегистрирован: Пн апр 02, 2007 19:03
Сообщений: 9

Bigarov Ruslan писал(а):

snmpwalk -v2c -c public 192.168.0.1 1.3.6.1.2.1.17.4.3.1.1

Спасибо, так видно.

Но только маки.

Чтобы получить порты нужно запускать команду повторно, но уже с

1.3.6.1.2.1.17.4.3.1.2

и для состояния

1.3.6.1.2.1.17.4.3.1.3

А чего оно само полное дерево не отдаёт?

Это фича? :)

Вернуться наверх

Профиль  

Bigarov Ruslan

Заголовок сообщения: Re: DES-2108: SNMP Error: OID not increasing

СообщениеДобавлено: Пн дек 24, 2007 14:16 



Зарегистрирован: Пт янв 21, 2005 11:52
Сообщений: 11211
Откуда: D-Link, Moscow

Потому что один OID — это один параметр.

_________________
С уважением,

Бигаров Руслан.

Вернуться наверх

Профиль  

yuray10

Заголовок сообщения:

СообщениеДобавлено: Пн дек 24, 2007 15:58 

Не в сети



Зарегистрирован: Пн апр 02, 2007 19:03
Сообщений: 9

Такое поведение несколько отличается от железок других

производителей.

Кстати, если спросить .1.3.6.1.2.1.2 (такую же таблицу, что и dot1dTpFdbTable)

то отдаётся всё дерево сразу, за один запрос.

Вернуться наверх

Профиль  

Demin Ivan

Заголовок сообщения:

СообщениеДобавлено: Пн дек 24, 2007 18:00 



Зарегистрирован: Пт май 13, 2005 15:49
Сообщений: 20616
Откуда: D-Link, Moscow

В этой серии для экономии ресурсов сделано именно так.

Вернуться наверх

Профиль  

yuray10

Заголовок сообщения:

СообщениеДобавлено: Вт дек 25, 2007 09:43 

Не в сети



Зарегистрирован: Пн апр 02, 2007 19:03
Сообщений: 9

Вернуться наверх

Профиль  


The preview effect may be slightly different from that of the source document. You can download the document and view it on your local PC.

Контент

Описание проблемы

Customer use version ME60 V100R006C05SPC600. NMS monitor a lot of parameters using SNMP. One of parameter is query ME60 to know which interface belong to which Eith-trunk. OID value that used for it is 1.3.6.1.4.1.2011.5.25.41.1.4.1.1.2, but when try query it, receive error:

snmpwalk -c

community_name -v2c  ip_address 1.3.6.1.4.1.2011.5.25.41.1.4.1.1.2
SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.0.738197889 = INTEGER: 1
SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.0.201326977 = INTEGER: 1
Error: OID not increasing: SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.0.738197889 >= SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.0.201326977

Информация сигнализации

Обработка

This is will be fixed at new version V6R3C05 (planed release April 2012). As workaround use snmpwalk utility with key «-C -c». After key is applyed output is normal:

# snmpwalk -c community_name

-C c -v2c ip_address 1.3.6.1.4.1.2011.5.25.41.1.4.1.1.2
SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.0.738197889 = INTEGER: 1
SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.0.201326977 = INTEGER: 1
SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.0.469762433 = INTEGER: 1
SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.1.268435841 = INTEGER: 1
SNMPv2-SMI::enterprises.2011.5.25.41.1.4.1.1.2.1.335544705 = INTEGER: 1

Основная причина

ME60 don’t follow strictly to rfc standard.

Предложения

According description of snmpwalk utility this error indicate that SNMP database at device don’t keep these parameters as ordered list, so utility can not interact with ME60 at standard manner.
There is RFC 2578 that require place parameters as order list:
3.5. OBJECT IDENTIFIER values
An OBJECT IDENTIFIER value is an ordered list of non-negative
numbers. For the SMIv2, each number in the list is referred to as a
sub-identifier, there are at most 128 sub-identifiers in a value, and
each sub-identifier has a maximum value of 2^32-1 (4294967295
decimal).

I have a problem scanning one of my L3 switches using SNMP. I am sure the community string is valid, I am even able to snmpwalk the device. I got the following error:

Test failed: Timed out. Bad authorization or device is offline.

And no — the device is online…

The device is a GigaRack 5280 L3 Fast/Gigabit Ethernet Switch (I know, I know…)

attach_file
Attachment

2011-05-31_test.png
6.51 KB

check
Best Answer

  • Author Josef Škurek

    OP
    skurekj


    This person is a Verified Professional

    This person is a verified professional.

    Verify your account
    to enable IT peers to see that you are a professional.

    serrano

    Weirdly enough, it seems to be the firewall issue. I am still looking into it, but even with 161 UDP enabled this particular switch has a problem.

    I dropped the firewall completely and voilà SNMP V1 passed.

    I am still going wireshark on the whole thing, thank you for your help, Brian

    P. S.: The OID not increasing thing is still there, but not related to the scanning issue


    Was this post helpful?
    thumb_up
    thumb_down

  • View Best Answer in replies below

    Read these next…

    • Curated Roku TV being used as Wallboard Issues

      Roku TV being used as Wallboard Issues

      Hardware

      Helping someone out at their shop. They have 4 large Roku screens and 2 laptops with dual HDMI ports for video. They are viewing static website business dashboards and PowerPoint. At first all 4 screens connected to wireless, worked for a while but with a…

    • Curated Charging for SSO

      Charging for SSO

      Security

      We have SSO set up with around 5 or 6 solution providers via our M365. Not one of them charges for this, they just sent us the documentation.I identified another online service in use by one of our departments which would benefit from using SSO for staff …

    • Curated Spark! Pro series - 9th February 2023

      Spark! Pro series — 9th February 2023

      Spiceworks Originals

      Today in History: America meets the Beatles on “The Ed Sullivan Show”

      At approximately 8:12 p.m. Eastern time, Sunday, February 9, 1964, The Ed Sullivan Show returned from a commercial (for Anacin pain reliever), and there was Ed Sullivan standing …

    • Curated Green Brand Rep Wrap-Up: January 2023

      Green Brand Rep Wrap-Up: January 2023

      Spiceworks Originals

      Hi, y’all — Chad here. A while back, we used to feature the top posts from our brand reps (aka “Green Gals/Guys/et. al.) in a weekly or monthly wrap-up post. I can’t specifically recall which, as that was approximately eleven timelines ago. Luckily, our t…

    • Curated Help with domain controller setup

      Help with domain controller setup

      Windows

      I just got a new job as the only IT person for a business with around 270 employees (I would say probably less than half use computers) They don’t have any policies or procedures when it comes to IT, as they have never had an IT person. My background cons…

    At work, I’m currently working with python-agentx to implement an AgentX-based SNMP agent. Testing around with snmpwalk, I got the following error:

    $ snmpwalk -Of -v2c -c public localhost DFS-HW-MIB::cpus
    .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusNumber = INTEGER: 2
    .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.0 = INTEGER: 0
    .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.cpuIndex.1 = INTEGER: 0
    .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.cpuIndex.2 = INTEGER: 1
    .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.cpuStatus.1 = INTEGER: OK(1)
    .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.cpuStatus.2 = INTEGER: OK(1)
    .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.cpuNumCores.1 = INTEGER: 2
    Error: OID not increasing: .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.cpuStatus.2
    >= .iso.org.dod.internet.private.enterprises.dfs.systemhaus.dfsHwMIB.cpus.cpusTable.cpuEntry.cpuNumCores.1
    


    While this error can be surpressed with snmpwalk’s -Cc switch, this is not a real solution as one can not always influence the behaviour of third party SNMP applications. So where does the error come from?

    With python-agentx, you declare a table like this:

    	axd.Table(
    		"cpuEntry",
    		{
    			"cpuIndex"	: [ 0, 1 ],
    			"cpuDesc"	: [ "Boar 6000", "Boar 6000" ],
    			"cpuNumCores"	: [ 2, 2 ],
    			"cpuTemp"	: [ 45, 47 ],
    			"cpuStatus"	: [ 1, 1 ]
    		}
    	)
    

    This gives you rows named cpuEntry.X with columns cpuIndex.X, cpuDesc.X, cpuNumCores.X, cpuTemp.X and cpuStatus.X. Naturally, your associated MIB must contain mappings to numerical OIDs for each element.

    Now section 7.2.3.2 of RFC 2741 speaks about a “lexicographically ordered list of variable names”, which is what snmpwalk checks for. Basically this means, that if cpuIndex translates to 1.1, then cpuDesc must be 1.2, cpuNumCores must be 1.3 etc. — cpuIndex being 1.4 and cpuDesc being 1.3 would be invalid if traversal using the SNMP “Get Next” command occurs the way it was defined above.

    And that’s exactly the point: if using a Python dictionary (that’s what the {} imply), there is no predictable order. Traversing the dictionary with a for x in... loop such as used by python-agentx will lead to snmpwalk getting elements returned with arbitrarily “jumping” OIDs, as can be seen above.

    In order to avoid this error, dictionaries would have to maintain the declaration order. While there is such a class, OrderedDict, it is not part of standard Python 2.x, so I went for a different solution using a list of tuples:

    	axd.Table(
    		"cpuEntry",
    		[
    			("cpuIndex",	[ 0, 1 ]),
    			("cpuDesc",	[ "Boar 6000", "Boar 6000" ]),
    			("cpuNumCores",	[ 2, 2 ]),
    			("cpuTemp",	[ 45, 47 ]),
    			("cpuStatus",	[ 1, 1 ])
    		]
    	)
    

    Lists do maintain declaration order, so with this simple concept we can avoid a OrderedDict dependency with a simple two-linge change to the python-agentx module.

    The patch can be found at Sourceforge Bug report #3518403.

    Понравилась статья? Поделить с друзьями:
  • Error of set pic flash addr
  • Error of principle
  • Error of loading of the data перевод
  • Error of judgement перевод
  • Error of indirect measurements