I’m trying to monitor BGP session on Nexus 3k and Nexus 9k with SNMP
With both equipment and with different NX-OS I’ve got same issue:
snmpwalk -v2c -c my.community -m ALL 172.21.21.1 220.127.116.11.18.104.22.168.1
BGP4-MIB::bgpEstablished = No Such Object available on this agent at this OID
On Nexus it looks that OID exists …
witch(config)# sh snmp internal translate oidorname bgp | include bgpEstablished
I’ve read that is related to VRF but in my case BGP and OSPF are running into default context
— my config –
snmp-server contact firstname.lastname@example.org
snmp-server location MY-LOCATION
snmp-server context default vrf default
snmp-server community my.community group network-operator
snmp-server mib community-map my.community context default
snmp-server community my.community use-ipv4acl snmp-acl-in
Any idea what occurs here?
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.
I hope this has been helpful!
I’ve finally solve the issue …
You need to add routing instance to context as this:
snmp-server context default instance [routing_instance_name] vrf default
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.
It’s great news that you’ve been able to resolve the issue! Thank you for sharing your solution, it helps so much to enrich the content of the forum.
Once again, thank you for your contribution!