I'm having the following problem with the RFC1286-MIB (dot1dBridge) using
NET-SNMP. It works with snmpwalk but not with snmpget:
#snmpwalk [ipaddress] [string] dot1dBridge.dot1dTp.dot1dTpFdbTable
it shows the information asked
but....
#snmpget [ipaddress] [string] dot1dBridge.dot1dTp.dot1dTpFdbTable
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
This name doesn't exist: dot1dBridge.dot1dTp.dot1dTpFdbTable.0
I've just added the RFC1286-MIB. I copied it to the mibs directory and then
reset the MIBS variable to ALL.
Can anyone please help me?
Thanks.
Gabriel
This is a pretty basic question. I suggest that you read a book
on SNMP. However, the snmpwalk program uses the SNMP GETNEXT
operation, which returns the lexi-next object instance.
But the snmpget program uses SNMP GET operation that requires
that you specify the OID of an object instance, and you
didn't. (You can only specify the OID value of instances
of columnar and scalar objects and not table or entry
object types.)
Regards,
/david t. perkins
Try:
#snmpgetnext [ipaddress] [string] dot1dTpFdbPort
Best regards,
Alex Rozin
Cheers,
Gabriel
"Gabriel Caffarena" <g.caf...@ic.ac.uk> wrote in message
news:9ed6tv$he2$1...@jura.cc.ic.ac.uk...
>I'm having the following problem with the RFC1286-MIB (dot1dBridge) using
>NET-SNMP. It works with snmpwalk but not with snmpget:
>
>#snmpwalk [ipaddress] [string] dot1dBridge.dot1dTp.dot1dTpFdbTable
>it shows the information asked
>
>but....
>
>#snmpget [ipaddress] [string] dot1dBridge.dot1dTp.dot1dTpFdbTable
>Error in packet
>Reason: (noSuchName) There is no such variable name in this MIB.
>This name doesn't exist: dot1dBridge.dot1dTp.dot1dTpFdbTable.0
Well, the most obvious reason is that there is no such object for
snmpget - the snmpget command is not being given a complete OID
since - the OID indexing below dot1dTpFdbTable is missing. If you did
a snmpgetnext, they you should get the first entry in the
dot1dTpFdbTable. snmpget, however, does not walk tables.
I earlier replied pointing out that sometimes it is the case that
vendor implementations do have bugs so that an OID that is encountered
as output via snmpwalk (which uses snmpgetnext) cannot be retrieved by
snmpget, or the other way around. Furthermore, sometimes vendors have
bugs so that snmpwalk goes into an infinite loop. But I missed the
obvious answer, that the snmpget command you were using had to fail
because you weren't pointing at a specific dot1dTpFdbTable entry.
Carl
Carl
Antispam address: In order to reply, change NoSpam to tiac.