No Such Instance / Object

noSuchObject and noSuchInstance are two specific exception values SNMPv2c/v3 agents return when a requested OID can't be satisfied - introduced specifically so a failed lookup for one OID in a request doesn't have to fail the entire request the way it did in SNMPv1. They look similar and get confused constantly, but they mean genuinely different things.

noSuchObject: the object itself isn't defined here

This means the OID you asked about doesn't correspond to any object this agent knows about at all - not a specific row's data missing, but the underlying column or scalar itself not being implemented. You'd see this if you queried an OID for a MIB or feature this particular device simply doesn't support - asking a device with no wireless capability for a wireless-specific statistic, for example.

noSuchInstance: the object exists, but not this particular instance

This means the agent does recognize the object you're asking about - the column is real and implemented - but the specific instance you requested doesn't currently exist. The classic example: a table column is real and well-defined, but you asked for row 99 when the device only actually has rows 1 through 24 (say, a 24-port switch). The column exists; that particular row doesn't.

Why the distinction is actually useful

These two values tell you where to look next. noSuchObject generally means "this device doesn't support this at all" - check whether the feature or MIB genuinely applies to this hardware. noSuchInstance means "you asked for the wrong specific row" - check your indexing, since the object itself is fine and the problem is almost certainly which instance you asked for, not whether it's supported.

endOfMibView: a third, related value

Walking operations (GETNEXT/GETBULK) have a third related value, endOfMibView, returned when you've walked past the very last OID the agent has - this isn't an error either, it's the expected, correct signal that there's genuinely nothing more to enumerate in that direction.

A common practical mistake

A frequent source of confusion: querying a table column's OID directly, without any instance suffix at all - e.g. 1.3.6.1.2.1.2.2.1.2 instead of 1.3.6.1.2.1.2.2.1.2.1. The bare column OID is not-accessible by design (see OBJECT-TYPE) - it's a template describing every row's structure, not a queryable value itself - so this correctly returns noSuchObject, even though the object is genuinely well-defined and rows of it exist. The fix is simply appending the correct instance index for the row you actually want.