search

kentik / snmp-profiles

SNMP Profiles for ktranslate
Apache License 2.0
24 stars 66 forks source link

[Bug] - Envmon MIB should not reference entitymib in tags in cisco-all-devices.yml #125

Closed araddas closed 2 years ago

araddas commented 2 years ago

Currently the CISCO-ENVMON-MIB in cisco-all-devices.yml is tagging entity_index, entity_description, entity_class, entity_name, entity_serial, entity_model using the index from the CISCO-ENVMON-MIB, this not valid and should be removed from this profile.

snmp walk of ciscoEnvMonSupplyStatusDescr and entPhysicalDescr envmon_entity_description_incorrect

NewRelic UI

Screen Shot 2022-01-07 at 10 32 41 AM
Mesverrum commented 2 years ago

This is going to take a bit to clear up, it looks like Cisco must have changed the way they treat this OID at some point because I have about a dozen walks in my collection that show correct mapping of all the ciscoEnvMonMIB indexes to the entPhysicalTable indexes, but now that I'm digging through them I also have some where they behave the way your device is showing. So far it seems to be inconsistent across a wide range of firmware versions and models. I have walks from catalysts, ios routers, and nx-os devices that all exhibit both patterns.

example from a 3750 stack where the indexes match up correctly entity_description .1.3.6.1.2.1.47.1.1.1.1.2.1003 = String: "Switch 1 - WS-C3750G-48TS - Power Supply 0" .1.3.6.1.2.1.47.1.1.1.1.2.2003 = String: "Switch 2 - WS-C3750G-48TS - Power Supply 0" entity_name .1.3.6.1.2.1.47.1.1.1.1.7.1003 = String: "Switch 1 - WS-C3750G-48TS - Power Supply 0" .1.3.6.1.2.1.47.1.1.1.1.7.2003 = String: "Switch 2 - WS-C3750G-48TS - Power Supply 0" power_status_description (the same oid you show in your walk snippet) .1.3.6.1.4.1.9.9.13.1.5.1.2.1003 = String: "Sw1, PS1 Normal, RPS NotExist" .1.3.6.1.4.1.9.9.13.1.5.1.2.2003 = String: "Sw2, PS1 Normal, RPS NotExist"

As an interim work around while we try to figure out how to identify which cisco gear does and does not use the entity indexes you could facet on power_status_description instead, but I wouldn't be surprised if you also have both kinds of devices in your environment.

i3149 commented 2 years ago

Talked with @cmcgrath138 , we decided that the best bet is to probably just facet on power_status_description.

Mesverrum commented 2 years ago

Looks like there isn't a clear solution we can implement on our end that covers both scenarios, so the workaround is just to have users use power_status_description or entity_description as necessary for their devices.