On 03-06-16 23:31, o...@leferguson.com wrote: > 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.
Recently I had to debug a similar issue. Of course there are a few factors that determine how large a response PDU is; I'd like to point out that there are at least two ways how a large response may not make it back to the requester. 1) IP MTU mismatch: when the SNMP agent (the ASA in this case) is configured to support jumbo frames (Ethernet) and has a larger IP MTU (> 1500), a large response PDU will be put in a large IP packet. It's UDP transport; sender and receiver do not negotiate about payload size. A large response may be dropped at various points in the path. 2) No MTU mismatch, but firewall rules that don't allow fragmented IP: when the SNMP agent builds a response PDU that is larger than the payload that will fit with the IP MTU, the result will be that the response is split over an initial IP packet (that includes the UDP header and first part of the payload), followed by one or more IP fragments with the rest of the UDP payload. Some networks filter IP fragments for security reasons. Especially SNMP GETBULK responses can get pretty big, depending on both the request parameters (like MaxRepetitions) and table design: both OID length (eg tables with text-based indexes or indexes based on large address fields) and value size play a role. So when you get partial results or no results, always consider whether response size could somehow be an issue. Regards, Jeroen ------------------------------------------------------------------------------ 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
