That should've been a "walk": pelle@kanelbulle:~$ snmpwalk rabbit .1.3.6.1.4.1.9.9.613 CISCO-EVC-MIB::ciscoEvcMIB = No Such Object available on this agent at this OID pelle@kanelbulle:~$
-- Pelle "D’ä e å, vett ja”, skrek ja, för ja ble rasen, ”å i åa ä e ö, hörer han lite, d’ä e å, å i åa ä e ö" - Gustav Fröding, 1895 On 15 October 2013 13:24, Per Carlson <[email protected]> wrote: > Hi Nick. > > Nope, a numerical OID doesn't help at all (I did try that before posting). > > pelle@kanelbulle:~$ snmpget rabbit .1.3.6.1.4.1.9.9.613 > CISCO-EVC-MIB::ciscoEvcMIB = No Such Object available on this agent at this > OID > pelle@kanelbulle:~$ > > -- > Pelle > > "D’ä e å, vett ja”, skrek ja, för ja ble rasen, > ”å i åa ä e ö, hörer han lite, d’ä e å, å i åa ä e ö" > - Gustav Fröding, 1895 > > > On 15 October 2013 13:09, Nick Hilliard <[email protected]> wrote: >> On 15/10/2013 13:51, Per Carlson wrote: >>> I'm trying to retreive some data from this MIB, but the switch doesn't >>> have any objects under this MIB (BTW, SNMP is working because I can >>> retreive data from other MIBs). >> >> is mib lookup broken? what happens when you try a numeric oid, e.g. >> >>> snmpwalk -v 2c -c blah switch.example.com .1.3.6.1.4.1.9.9.613.1.2.1.1.1 >> >> This should return some index values, e.g. >> >>> SNMPv2-SMI::enterprises.9.9.613.1.2.1.1.1.5003 = INTEGER: 1 >>> SNMPv2-SMI::enterprises.9.9.613.1.2.1.1.1.10101 = INTEGER: 1 >>> SNMPv2-SMI::enterprises.9.9.613.1.2.1.1.1.10102 = INTEGER: 1 >>> SNMPv2-SMI::enterprises.9.9.613.1.2.1.1.1.10103 = INTEGER: 1 >>> SNMPv2-SMI::enterprises.9.9.613.1.2.1.1.1.10104 = INTEGER: 1 >> [...] >> >> (tested on 15.3(2)S). >> >> Nick >> >> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
