Hmm, that’s an interesting problem. It seems that the object should be accessible since it does appear that there is any misconfiguration. After doing some research, you may find some of the following helpful:
To ensure that the problem is with the specific OID only, try to execute an snmpwalk on other OIDs that are on the device, to see what response you get from those. This will enable you to determine if the problem is with the specific OID or with the SNMP configuration in general.
This issue has been seen in some bugs with Nexus devices, and I have seen some TAC cases opened for this. If this is a production network, you may find it helpful to open a TAC case. But since you are seeing this in two different platforms with different NX-OS versions, it may not be the case.
I have seen some cases (in a non-Cisco environment) where the main agent needs to query the subagent for the object being requested, and for that to happen it needs a mapping from the subtree OID to the subagent.
Hopefully, some of these thoughts will help you in your troubleshooting process.
What occurs in my case is I’ve name each instance with a different name: ospf, ospf-ipv6, bgp
I don’t know if you can have different routing protocols with same instance name for example “default”
So the only solution is create different context and v2 community mapped to each routing instance.
On NMS side (such PRTG) you need add various time same device with different SNMP community and proper OID to each one.