On 7 August 2012 06:57, Dave Hsu <[email protected]> wrote:
> Using Perl. I have a total of 2085 oids in an array (for the same one
> equipment). Most of the oids are for ifHCIn/OutOctets. Others for discards,
> inputerror etc.
>
> Session is created (successfully) by setting maxmsgsize to 65535.
Presumably this is being done on the client side?
> Then I use:
>
> $result = $session->get_request(-varbindlist => \@oids,);
>
> It gives me this:
> ERROR: No response from remote host.
>
> When I reduce the number of oids in the above array to around 60 I get the
> response successfully.
>
> Questions:
> 1) Where is the bottleneck?
> 4) Can/should something be changed on the host(router)?
My guess is that although the client is saying that it's willing to
deal with requests up to 65535 in size, the agent may not be able
to handle this. If there are size limitations within the agent code,
then simply setting the client side configuration won't automatically
overcome this.
Remember that this is effectively a negotiation between the two
sides, to determine the largest size that is mutually acceptable.
You don't say anything about the version of SNMP that you're using.
I've also had a very quick look at the Net-SNMP code, and it looks
as if the size negotiation is only relevant to SNMPv3.
With community-based versions, the maximum size accepted by
the SNMP agent
"... may be known on a per-recipient basis..."
(i.e. you need to look in the documentation for the router,
or ask the vendor)
"... [or] is indicated by the transport domain used when sending
the message" RFC 1905, section 2.5
(i.e. you can't assume anything larger than 484 bytes - see RFC 1906)
Dave
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
