Hans, thank you for the answer. Some stuff embedded at LEF>
-----Original Message-----
From: Hans Jørgen Jakobsen [mailto:h...@wheel.dk]
Sent: Friday, June 3, 2016 2:39 PM
To: o...@leferguson.com
Cc: net-snmp-users@lists.sourceforge.net
Subject: RE: SNMP Perl question: Limits on gettable?
On Wed, 1 Jun 2016, o...@leferguson.com wrote:
> No one? Wrong place to ask? Ill formed question? Any hints?
I will try.
I have not used gettable in perl.
I wasn't aware that it was possible to specify selected coloums.
Have you tried the CLI snmptable? do it give all values?
Do snmpwalk throw some out of sequence warnings?
LEF> yes,CLI works fine, though what it returns is just the indexes and not the
hash structure with decoded values that this table gives in perl.
>
> Generally it is working, but I have one routine that attempts to query a
> cisco table as below, and in most cases it works, but for one large ASA with
> a lot of tunnels, it fails to return all rows in the table, returning what
> appears to be a random subset of about half of them. Using the snmpwalk
> command works fine.
>
> The code is as follows:
>
> my %snmpparms;
> $snmpparms{Community} = $community;
> $snmpparms{DestHost} = inet_ntoa(inet_aton($IP));
> $snmpparms{Version} = "2";
> $snmpparms{UseSprintValues} = '1';
> $snmpparms{UseEnums} = '0';
> $snmpparms{UseNumeric} = '0';
> $snmpparms{NonIncreasing} = '1';
> $snmpparms{Timeout}=10000000; # need long timeout for large tables over
> WAN
> $sess = new SNMP::Session(%snmpparms);
>
> # Now pull in the correlation table so we know which are real tunnels
> my $RtnCorrHash = (
> $sess->gettable('CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrTable') );
>
>
> I've tried various combinations of the options in the session parameters
> without any change. I've also tried placing a column list on the gettable
> without any change.
>
> I had this same problem with another large table and just converted it to
> specific calls to getbulk, but I rather liked using gettable in this case.
>
> There is no error returned from the gettable call. The data returned is
> correct just incomplete.
>
> There are 54 items in the table, and each one looks sort of like this; only
> 25 rows were returned the last few times I tried (I am not sure if it always
> stops at 25 or not):
>
>
> '1.13.51.56.46.49.52.48.46.49.51.52.46.49.56.1.11.xx.xx.xx.xx.x.xx.xx.
> .xx.46.xx.55.500.25126' => {
You might wish you had put some xx in above line :-)
LEF> Yeah, me too. Incidentally, all SNMPTABLE gives is the 2516 above.
>
> 'cikePeerCorrIntIndex' => '500',
>
> 'cikePeerCorrRemoteValue' => '50.xxx.xxx.77',
>
> 'cikePeerCorrRemoteType' => '1',
>
> 'cikePeerCorrSeqNum' => '25126',
>
> 'cikePeerCorrIpSecTunIndex' => '25126',
>
> 'cikePeerCorrLocalValue' => '38.xxx.xxx.18',
>
> 'cikePeerCorrLocalType' => '1'
>
>
> },
>
> The Cisco device is fairly new and on a high speed LAN; snmpwalk returns data
> very quickly, so I do not think this is some kind of timeout issue or
> anything related to packet fragmentation. I am pulling a lot of data from it
> via zabbix and all those queries work fine.
>
> Any ideas why it will not return all values?
There might be errors in impl of gettable... Problems I would look for:
1) This mib uses 2 text as index. This might be a challenge.
Do it handle text of different lengths?
2) I think the table is dynamib. What happens whem a row (dis)appear while
walking?
LEF> That definitely can happen but is not happening in this case; the problem
is 100% reproducible, but the table changes infrequently.
Try making tcpdump to figure out where and why it stops.
LEF> Good idea, though I do not know what to make of it. It captured exactly
two packets, the request and the (incomplete) answer.
LEF> The (not working) gettable request looks like this: GetBulk(33)
R=1924371077 N=0 M=200 .1.3.6.1.4.1.9.9.171.1.2.4 }
LEF> The (working) snmptable) request starts like this: GetBulk(34) R=957254588
N=0 M=10 .1.3.6.1.4.1.9.9.171.1.2.4.1.0
LEF> Notice it is returning 10 at a time, which appear to fit in one packet,
then it does another separate getbulk using the last returned index as a
starting point. Taking this as a guess I adjusted the "repeat" option to 10,
and this returns the correct answer. The documentation says:
##This calculation is fairly safe, hopefully, but you can either raise or lower
the
##number using this option if desired. In lossy networks, you want to make
##sure that the packets don't get fragmented and lowering this value
##is one way to help that.
LEF> The network is not lossy, though I guess it is possible the target ASA has
some kind of limitation on its return packet sizes. Regardless, it would
appear the API (vs. CLI) calculation is optimistic about how much data it can
get in 1000 bytes (mentioned elsewhere), at least for this table. Frankly 100
seems large regardless as an arbitrary guess, the responses would need to be
very tiny. The actual packet responded was complete (as in well structured,
not truncated), and checksum matched.
Be aware that you probable will spend more time debuging than rewriting the
code to use snmp(bulk)walk :-) /hjj
LEF> Actually I did that shortly after writing this, at this point it is more
curiosity.
LEF> So this discussion does give me a fix, though at this point not sure I
will go back and change the (working) code. Perhaps the maintainers will find
some use in the discussion and example, and consider if the defaults are
appropriate. I'm not sure if there is some way to know from the data received
if the initial response was complete -- maybe it presumes since less than the
requested number came back, it is complete (that would seem to make sense), but
it definitely is not in this case.
LEF> Thank you for the response. I had assumed TCPDUMP would not help, really,
since it was so repeatable I presumed it was not a network issue (and indeed it
is not, at least in terms of loss). But the explicit request difference from
the CLI made it obvious.
Linwood
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
