it’s not “broken” in the sense that CSCO officially considers multicontext snmp the “by-design” method (and I have the TAC cases to prove it).
remember, snmp *works* which means it’s for grouchy old [grey|neck]beards.
netconf & shiny-api-disaster-of-the-week are supposed to rule the new agile! world! of! devops! ( *gag* )
not just ASRs … for instance, it’s the same thing (multicontext snmp hell) with VRFs on n7k’s.
so, it’s a “feature” not a “bug”
smh
R.
Because the MIB is broken and doesn?t have any concept of VRF awareness.The workaround that I used on my ASR9Ks was to create a different context for the VRF in question.This config example basically treats the vrf Inetv4 as the default vrf when polling with community blahpoo. It only applies to that community. I have non-contextual communities to catch my default stuff, i.e. my MP-BGP underpinnings.It?s not ideal because you need to create two of the same device in Observium; one for each community (vrf and non-vrf), but it sucks less than the alternative, which is to not have this functionality at all.!snmp-server vrf Inetv4context BGPVRF!snmp-server context BGPVRFsnmp-server community-map blahpoo context BGPVRFsnmp-server community blahpoo RO MANAGEMENT!http://postman.memetic.org/pipermail/observium/2015-June/010467.html