Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
no response from devices when querying multiple oids
662 views
Skip to first unread message
Aleksandrs Saveljevs
Nov 15, 2013, 4:10:11 AM11/15/13
to
Good morning,
We have some SNMP devices that do not respond to queries where the
number of OIDs is over a certain limit. That is, they do respond to
queries with N OIDs in the request, but return no response to queries
with N+1 and more OIDs.
We have originally discussed the issue on #net-snmp IRC channel, but
since there was no definite conclusion, we are moving the discussion
here on the mailing list.
Let me summarize what we have already talked about on IRC.
First, we walk a device to obtain a list of OIDs it supports:
$ snmpwalk -v 2c -c public 192.168.1.1 > walk.txt
Then, we query a number of OIDs from that walk in a single GET request:
$ head -29 walk.txt | cut -d' ' -f1 | xargs snmpget -d -r 0 -v 2c -c
public 192.168.1.1
This responds normally with a 650 byte packet from UDP containing values
for 29 variables.
However, if we replace "29" in the above command with "30", then there
is no response: "Timeout: No Response from 192.168.1.1."
The problem might have to do with the fact that devices might have a
limit on the size of the message they can produce. However, in that case
we would expect the device to send a response with "tooBig" error code.
Indeed, one of the devices we have does that:
$ head -100 walk.txt | cut -d' ' -f1 | xargs snmpget -r 0 -v 1 -c public
192.168.1.2
Error in packet
Reason: (tooBig) Response message would have been too large.
Apparently, the device at 192.168.1.1 does not respond with "tooBig" and
we wish to understand why. Is it a common behavior for devices and does
it conform to some sort of specification? Maybe there is an object in
one of the MIBs that controls it?
For instance, it was suggested on IRC that SNMPv2-MIB::snmpSilentDrops
might give a clue, but there is no such OID on this device, which is a
respectable D-Link firewall:
$ snmpget -v 2c -c public 192.168.1.1 SNMPv2-MIB::snmpSilentDrops
SNMPv2-MIB::snmpSilentDrops = No Such Object available on this agent at
this OID
Another interesting observation is that using "snmpbulkget" can elicit a
response with size much larger than the one "snmpget" fails at:
$ head -29 walk.txt | cut -d' ' -f1 | xargs snmpbulkget -d -r 0 -v 2c -c
public -Cn29 -Cr0 192.168.1.1
This works and we receive a response with 622 byte packet from UDP.
Similar to "snmpget", replacing "29" with "30" gives no response.
However, using "max-repetitions" instead of "non-repeaters" allows to
get more values:
$ head -1 walk.txt | cut -d' ' -f1 | xargs snmpbulkget -d -r 0 -v 2c -c
public -Cn0 -Cr47 192.168.1.1
This works, too, and response of size 1020 bytes is received. Similarly,
replacing "47" with "48" gives a timeout.
If you could share your thoughts on the topic, that would be wonderful.
Thank you,
Aleksandrs
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
We have some SNMP devices that do not respond to queries where the
number of OIDs is over a certain limit. That is, they do respond to
queries with N OIDs in the request, but return no response to queries
with N+1 and more OIDs.
We have originally discussed the issue on #net-snmp IRC channel, but
since there was no definite conclusion, we are moving the discussion
here on the mailing list.
Let me summarize what we have already talked about on IRC.
First, we walk a device to obtain a list of OIDs it supports:
$ snmpwalk -v 2c -c public 192.168.1.1 > walk.txt
Then, we query a number of OIDs from that walk in a single GET request:
$ head -29 walk.txt | cut -d' ' -f1 | xargs snmpget -d -r 0 -v 2c -c
public 192.168.1.1
This responds normally with a 650 byte packet from UDP containing values
for 29 variables.
However, if we replace "29" in the above command with "30", then there
is no response: "Timeout: No Response from 192.168.1.1."
The problem might have to do with the fact that devices might have a
limit on the size of the message they can produce. However, in that case
we would expect the device to send a response with "tooBig" error code.
Indeed, one of the devices we have does that:
$ head -100 walk.txt | cut -d' ' -f1 | xargs snmpget -r 0 -v 1 -c public
192.168.1.2
Error in packet
Reason: (tooBig) Response message would have been too large.
Apparently, the device at 192.168.1.1 does not respond with "tooBig" and
we wish to understand why. Is it a common behavior for devices and does
it conform to some sort of specification? Maybe there is an object in
one of the MIBs that controls it?
For instance, it was suggested on IRC that SNMPv2-MIB::snmpSilentDrops
might give a clue, but there is no such OID on this device, which is a
respectable D-Link firewall:
$ snmpget -v 2c -c public 192.168.1.1 SNMPv2-MIB::snmpSilentDrops
SNMPv2-MIB::snmpSilentDrops = No Such Object available on this agent at
this OID
Another interesting observation is that using "snmpbulkget" can elicit a
response with size much larger than the one "snmpget" fails at:
$ head -29 walk.txt | cut -d' ' -f1 | xargs snmpbulkget -d -r 0 -v 2c -c
public -Cn29 -Cr0 192.168.1.1
This works and we receive a response with 622 byte packet from UDP.
Similar to "snmpget", replacing "29" with "30" gives no response.
However, using "max-repetitions" instead of "non-repeaters" allows to
get more values:
$ head -1 walk.txt | cut -d' ' -f1 | xargs snmpbulkget -d -r 0 -v 2c -c
public -Cn0 -Cr47 192.168.1.1
This works, too, and response of size 1020 bytes is received. Similarly,
replacing "47" with "48" gives a timeout.
If you could share your thoughts on the topic, that would be wonderful.
Thank you,
Aleksandrs
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
"Fredrik Björk"
Nov 15, 2013, 5:03:29 PM11/15/13
to
Hi!
First of all, use snmpbulkwalk as much as you can on SNMP v2c or v3
devices, it is much faster than snmpwalk.
root@fw01:~# head -150 walk.txt | cut -d' ' -f1 | xargs snmpget -d -r 0 -v
2c -c public 10.67.11.254
Too many object identifiers specified. Only 128 allowed in one request.
OK, 128 is allowed by snmpget.
root@fw01:~# head -104 walk.txt | cut -d' ' -f1 | xargs snmpget -v 2c -c
public 10.67.11.254
yields 103 replies. Up to head -128 is OK for the 400 even if the reply is
tooBig (which probaly is entirely correct). At least it responds the way
it should.
Now for my Trapeze/Juniper MX-200 controller (yes, I actually do have a
wireless cluster at home :) ):
root@fw01:~# head -127 walk.txt | cut -d' ' -f1 | xargs snmpget -v 2c -c
public 10.10.20.11
public 10.10.20.11
Timeout: No Response from 10.10.20.11.
root@fw01:~# head -129 walk.txt | cut -d' ' -f1 | xargs snmpget -v 2c -c
public 10.10.20.11
Too many object identifiers specified. Only 128 allowed in one request.
Apparently, Trapeze fails to respond to a request with 128 OIDs in it, and
snmpwalk refuses 129. 127 is rejected based on tooBig. The 128 case should
probably be considered a difference in interpretation of a limit I guess.
Extreme BD10k and X450/460 allows 128 but returns tooBig.
Motorola BSR 1000 (DOCSIS CMTS) allows 126 but not 127 OIDs.
Motorola BSR 2000 allows 123 but not 124 OIDs.
Casa C2200 CMTS allows 128 OIDs.
Cisco 2821 router allows 111 but not 112. Of course, Cisco just has to
ruin everything with their non-standard way of things with a few line
breaks in the sysDescr response (never seen it in a non-cisco device), but
after filtering that out, it worked OK.
Why the difference? Ask the vendors. I'd say difference in implementation,
intended or unintended, not really a bug or anything.
/Fredrik
> Good morning,
> We have some SNMP devices that do not respond to queries where the
number of OIDs is over a certain limit. That is, they do respond to
queries with N OIDs in the request, but return no response to queries
with N+1 and more OIDs.
...
First of all, use snmpbulkwalk as much as you can on SNMP v2c or v3
devices, it is much faster than snmpwalk.
root@fw01:~# head -150 walk.txt | cut -d' ' -f1 | xargs snmpget -d -r 0 -v
2c -c public 10.67.11.254
Too many object identifiers specified. Only 128 allowed in one request.
OK, 128 is allowed by snmpget.
root@fw01:~# head -104 walk.txt | cut -d' ' -f1 | xargs snmpget -v 2c -c
public 10.67.11.254
Error in packet
Reason: (tooBig) Response message would have been too large.
That's my Extreme Summit 400 switch saying tooBig. head -103 is OK and
Reason: (tooBig) Response message would have been too large.
yields 103 replies. Up to head -128 is OK for the 400 even if the reply is
tooBig (which probaly is entirely correct). At least it responds the way
it should.
Now for my Trapeze/Juniper MX-200 controller (yes, I actually do have a
wireless cluster at home :) ):
root@fw01:~# head -127 walk.txt | cut -d' ' -f1 | xargs snmpget -v 2c -c
public 10.10.20.11
Error in packet
Reason: (tooBig) Response message would have been too large.
root@fw01:~# head -128 walk.txt | cut -d' ' -f1 | xargs snmpget -v 2c -c
Reason: (tooBig) Response message would have been too large.
public 10.10.20.11
Timeout: No Response from 10.10.20.11.
root@fw01:~# head -129 walk.txt | cut -d' ' -f1 | xargs snmpget -v 2c -c
public 10.10.20.11
Too many object identifiers specified. Only 128 allowed in one request.
Apparently, Trapeze fails to respond to a request with 128 OIDs in it, and
snmpwalk refuses 129. 127 is rejected based on tooBig. The 128 case should
probably be considered a difference in interpretation of a limit I guess.
Extreme BD10k and X450/460 allows 128 but returns tooBig.
Motorola BSR 1000 (DOCSIS CMTS) allows 126 but not 127 OIDs.
Motorola BSR 2000 allows 123 but not 124 OIDs.
Casa C2200 CMTS allows 128 OIDs.
Cisco 2821 router allows 111 but not 112. Of course, Cisco just has to
ruin everything with their non-standard way of things with a few line
breaks in the sysDescr response (never seen it in a non-cisco device), but
after filtering that out, it worked OK.
Why the difference? Ask the vendors. I'd say difference in implementation,
intended or unintended, not really a bug or anything.
/Fredrik
> Good morning,
> We have some SNMP devices that do not respond to queries where the
number of OIDs is over a certain limit. That is, they do respond to
queries with N OIDs in the request, but return no response to queries
with N+1 and more OIDs.
"Fredrik Björk"
Nov 15, 2013, 5:09:48 PM11/15/13
to
Hi!
What if you replace "head -29 walk.txt" with "head -100 walk.txt | tail
-29" to get another set of OIDs? Still 29 OK not 30? In that case, it's
definitely D-link just supporting 29 OIDs just because they didn't feel
more was required.
/Fredrik
PS dd-wrt on a WRT-54GL returns 128 variables upon request - that's REAL
software! /DS
> Good morning,
>
> We have some SNMP devices that do not respond to queries where the
> number of OIDs is over a certain limit. That is, they do respond to
> queries with N OIDs in the request, but return no response to queries
> with N+1 and more OIDs.
...
> $ head -29 walk.txt | cut -d' ' -f1 | xargs snmpget -d -r 0 -v 2c -c
> public 192.168.1.1
What if you replace "head -29 walk.txt" with "head -100 walk.txt | tail
-29" to get another set of OIDs? Still 29 OK not 30? In that case, it's
definitely D-link just supporting 29 OIDs just because they didn't feel
more was required.
/Fredrik
PS dd-wrt on a WRT-54GL returns 128 variables upon request - that's REAL
software! /DS
> Good morning,
>
> We have some SNMP devices that do not respond to queries where the
> number of OIDs is over a certain limit. That is, they do respond to
> queries with N OIDs in the request, but return no response to queries
> with N+1 and more OIDs.
...
> public 192.168.1.1
Aleksandrs Saveljevs
Nov 19, 2013, 3:59:28 AM11/19/13
to
I have played with your suggestion by querying a different set of OIDs
and I am starting to think it might a limit not on the response size or
the number of OIDs, but on the size of the inbound UDP packet.
So sometimes our device returned a response to 28 OIDs and failed on 29
OIDs, and sometimes it returned a response to 29 OIDs and failed on 30.
However, it was consistently returning responses when snmpget was
sending packets up to 484 bytes and not returning responses to requests
at least 485 bytes in size.
Aleksandrs
On 11/16/2013 12:09 AM, "Fredrik Björk" wrote:
> Hi!
>
> What if you replace "head -29 walk.txt" with "head -100 walk.txt | tail
> -29" to get another set of OIDs? Still 29 OK not 30? In that case, it's
> definitely D-link just supporting 29 OIDs just because they didn't feel
> more was required.
>
> /Fredrik
>
> PS dd-wrt on a WRT-54GL returns 128 variables upon request - that's REAL
> software! /DS
>
>> Good morning,
>>
>> We have some SNMP devices that do not respond to queries where the
>> number of OIDs is over a certain limit. That is, they do respond to
>> queries with N OIDs in the request, but return no response to queries
>> with N+1 and more OIDs.
> ...
>> $ head -29 walk.txt | cut -d' ' -f1 | xargs snmpget -d -r 0 -v 2c -c
>> public 192.168.1.1
>
>
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
and I am starting to think it might a limit not on the response size or
the number of OIDs, but on the size of the inbound UDP packet.
So sometimes our device returned a response to 28 OIDs and failed on 29
OIDs, and sometimes it returned a response to 29 OIDs and failed on 30.
However, it was consistently returning responses when snmpget was
sending packets up to 484 bytes and not returning responses to requests
at least 485 bytes in size.
Aleksandrs
On 11/16/2013 12:09 AM, "Fredrik Björk" wrote:
> Hi!
>
> What if you replace "head -29 walk.txt" with "head -100 walk.txt | tail
> -29" to get another set of OIDs? Still 29 OK not 30? In that case, it's
> definitely D-link just supporting 29 OIDs just because they didn't feel
> more was required.
>
> /Fredrik
>
> PS dd-wrt on a WRT-54GL returns 128 variables upon request - that's REAL
> software! /DS
>
>> Good morning,
>>
>> We have some SNMP devices that do not respond to queries where the
>> number of OIDs is over a certain limit. That is, they do respond to
>> queries with N OIDs in the request, but return no response to queries
>> with N+1 and more OIDs.
> ...
>> $ head -29 walk.txt | cut -d' ' -f1 | xargs snmpget -d -r 0 -v 2c -c
>> public 192.168.1.1
>
>
>
------------------------------------------------------------------------------
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
Aleksandrs Saveljevs
Nov 19, 2013, 6:38:16 AM11/19/13
to
I have played a bit more and the conjecture turned out to be (at least
partially) false.
The way I played was attempt to query string objects with long values:
$ snmpget -v 2c -c public 192.168.1.1 IF-MIB::ifAlias.3
IF-MIB::ifAlias.3 = STRING: Builtin r8139/8129 - Realtek RTL8139 Fast
Ethernet Bus 0 Slot
$ { for i in {1..13}; do echo 'IF-MIB::ifAlias.3'; done } | xargs
...
Timeout: No Response from 192.168.1.1.
So the device sends no response to a 254-byte request. If 12 copies are
queried, then it works OK by responding with a 1020-byte packet.
Aleksandrs
partially) false.
The way I played was attempt to query string objects with long values:
$ snmpget -v 2c -c public 192.168.1.1 IF-MIB::ifAlias.3
IF-MIB::ifAlias.3 = STRING: Builtin r8139/8129 - Realtek RTL8139 Fast
Ethernet Bus 0 Slot
$ { for i in {1..13}; do echo 'IF-MIB::ifAlias.3'; done } | xargs
snmpget -d -r 0 -v 2c -c public 192.168.1.1
Sending 254 bytes to UDP: [192.168.1.1]:161->[0.0.0.0]:0
...
Timeout: No Response from 192.168.1.1.
queried, then it works OK by responding with a 1020-byte packet.
Aleksandrs
Fulko Hew
Nov 19, 2013, 10:56:11 AM11/19/13
to
On Tue, Nov 19, 2013 at 6:38 AM, Aleksandrs Saveljevs <Aleksandrs...@zabbix.com> wrote:
I have played a bit more and the conjecture turned out to be (at least
partially) false.
The way I played was attempt to query string objects with long values:
$ snmpget -v 2c -c public 192.168.1.1 IF-MIB::ifAlias.3
IF-MIB::ifAlias.3 = STRING: Builtin r8139/8129 - Realtek RTL8139 Fast
Ethernet Bus 0 Slot
$ { for i in {1..13}; do echo 'IF-MIB::ifAlias.3'; done } | xargs
snmpget -d -r 0 -v 2c -c public 192.168.1.1Sending 254 bytes to UDP: [192.168.1.1]:161->[0.0.0.0]:0
...
Timeout: No Response from 192.168.1.1.
So the device sends no response to a 254-byte request. If 12 copies are
queried, then it works OK by responding with a 1020-byte packet.
I can't comment on your specific scenario, but I _do_ know that there
is a design limit in the strings accepted into snmpd via its AgentX
interface, and anything longer will be (semi-silently) dropped.
Perhaps the same implementation restriction also applies to strings
coming from other areas within snmpd.
is a design limit in the strings accepted into snmpd via its AgentX
interface, and anything longer will be (semi-silently) dropped.
Perhaps the same implementation restriction also applies to strings
coming from other areas within snmpd.
Because although the spec for OCTET STRINGS allows for 2^16
in length, there are also other words (and warnings) that say
'there can be other implementation-specific limitations'.
in length, there are also other words (and warnings) that say
'there can be other implementation-specific limitations'.
0 new messages