Jeff Gehlbach wrote: > The cfwBufferStatsTable that the OID above references has a compound > index, so the "2560" above is actually part of the instance > identifier. 2560 is the size of the buffer, so probably what's > happening here is that your device does not have a buffer of that > size. My guess is that the buffer sizes may differ from one IOS > release to the next, and that your ASA's IOS does not match that of > the one for which this collection definition was added. > > Run this command from the OpenNMS server, substituting your community > string: > > snmpwalk -v1 -c public 10.9.7.111 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4 >
The output of the snmpwalk command: .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.0.3 = Gauge32: 100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.0.5 = Gauge32: 99 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.0.8 = Gauge32: 100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.4.3 = Gauge32: 100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.4.5 = Gauge32: 99 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.4.8 = Gauge32: 99 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.80.3 = Gauge32: 700 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.80.5 = Gauge32: 696 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.80.8 = Gauge32: 700 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.256.3 = Gauge32: 612 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.256.5 = Gauge32: 593 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.256.8 = Gauge32: 612 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.1550.3 = Gauge32: 9246 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.1550.5 = Gauge32: 7669 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.1550.8 = Gauge32: 7728 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.2048.3 = Gauge32: 2100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.2048.5 = Gauge32: 2100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.2048.8 = Gauge32: 2100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.2560.3 = Gauge32: 40 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.2560.5 = Gauge32: 40 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.2560.8 = Gauge32: 40 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.4096.3 = Gauge32: 30 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.4096.5 = Gauge32: 30 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.4096.8 = Gauge32: 30 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.8192.3 = Gauge32: 60 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.8192.5 = Gauge32: 60 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.8192.8 = Gauge32: 60 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.16384.3 = Gauge32: 100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.16384.5 = Gauge32: 100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.16384.8 = Gauge32: 100 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.65536.3 = Gauge32: 10 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.65536.5 = Gauge32: 10 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.65536.8 = Gauge32: 10 As you see the "2560" buffer is there. The problem is when you do a snmpgetnext on .2560.2, you don't get back the .2560.3 OID but a different one: snmpgetnext -v2c -cpublic 10.9.7.1 .1.3.6.1.4.1.9.9.147.1.2.2.1.1.4.2560.2 output: .1.3.6.1.4.1.9.9.147.1.2.2.2.1.3.40.6 = STRING: "number of connections currently in use by the entire firewall" Am I missing something? Thanks! Niels ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
