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.
On Jan 13, 2016, at 07:00, observium-request@observium.org wrote:
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 Inetv4 context BGPVRF ! snmp-server context BGPVRF snmp-server community-map blahpoo context BGPVRF snmp-server community blahpoo RO MANAGEMENT !
http://postman.memetic.org/pipermail/observium/2015-June/010467.html http://postman.memetic.org/pipermail/observium/2015-June/010467.html