report MIB file errors

[STUART KENDRICK]

Where do I report MIB file errors?  The current v2.tar.gz contains the following:

guru$ snmptranslate

Did not find 'cldRegulatoryDomain' in module CISCO-LWAPP-DOT11-MIB (/usr/share/snmp/mibs/Cisco/CISCO-LWAPP-AP-MIB)

Did not find 'CtsSgaclMonitorMode' in module CISCO-TRUSTSEC-TC-MIB (/usr/share/snmp/mibs/Cisco/CISCO-TRUSTSEC-POLICY-MIB)

Did not find 'UnicastRpfType' in module CISCO-IP-URPF-MIB (/usr/share/snmp/mibs/Cisco/CISCO-DYNAMIC-TEMPLATE-MIB)

Did not find 'UnicastRpfOptions' in module CISCO-IP-URPF-MIB (/usr/share/snmp/mibs/Cisco/CISCO-DYNAMIC-TEMPLATE-MIB)

Did not find 'cldcClientAccessVLAN' in module CISCO-LWAPP-DOT11-CLIENT-MIB (/usr/share/snmp/mibs/Cisco/CISCO-LWAPP-SYS-MIB)

[...]

--sk

Stuart Kendrick

FHCRC

[Vlad Vlaicu]

Hello Stuart!

I could not find the specified MIB objects on

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en

Could you explain in more detail what is the concern?

Regards,

Vlad

[STUART KENDRICK]

Hi Vlad,

So, a few times a year, I grab the latest MIB file collection from ftp.cisco.com/pub/mibs and update my network mgmt stations.

In the current collection, some MIB files reference Object Values which are not defined anywhere, as you have noted.

For example, in the IMPORTS section of CISCO-LWAPP-AP-MIB, I see:

    cldRegulatoryDomain

        FROM CISCO-LWAPP-DOT11-MIB

But nowhere in CISCO-LWAPP-DOT11-MIB (nor in any other MIB file included in v2.tar.gz) is cldRegulatoryDomain defined

Now, I can comment out this import and get past this issue ... while CISCO-LWAPP-AP-MIB imports cldRegulatoryDomain, nowhere does it actually /use/ it ... so commenting out the import has no impact.

However CtsSgaclMonitorMode is used a /lot/ in CISCO-TRUSTSEC-TC-MIB ... and commenting out all those occurrences is a bit of a bear (CISCO-TRUSTSEC-TC-MIB tries to IMPORT it from CISCO-TRUSTEC-POLICY-MIB, which doesn't contain it ... )

Nothing new here -- I've been doing this for years, and each time I download v2.tar.gz, I find errors, which I either fix or dodge around ... but this time, the extent of these errors is slowing me down more than usual, so I figured I'd post here and see if I can find a longer term fix, or at least a way to help out by reporting what I find.

Your thoughts on how I might proceed?

--sk

[Reuben Farrelly]

I'm seeing this problem also.

The two warnings I am getting are:

Did not find 'cldRegulatoryDomain' in module CISCO-LWAPP-DOT11-MIB (/etc/snmp/wlc-ciscoftp/CISCO-LWAPP-AP-MIB.my)

Did not find 'cldcClientAccessVLAN' in module CISCO-LWAPP-DOT11-CLIENT-MIB (/etc/snmp/wlc-ciscoftp/CISCO-LWAPP-SYS-MIB.my)

Neither appear to be defined anywhere.

What is the process for getting these fixed?  There is an email address in the snmp mibs:

Email: cs-snmp@cisco.com

Is that the right channel to be contacting?

[stuartkendrick]

I still don't know what channel to use for reporting these issues.  But here are copies of updated versions of (2) MIB files -- using these in place of the ones currently visible at ftp.cisco.com/pub/mibs/v2 resolve a lot of these issues.

[Reuben Farrelly]

Not specifically to do with the wireless mibs, but I attempted to communicate with Cisco about some other faulty MIBs some months ago.  (There are still a few in the mib tree on CCO that have blatant syntax errors like invalid dates)

The contact email addresses in the MIB files should be a good way to contact someone about these errors, but more often than not these email addresses either bounce or never get a response.

I think there may be an SNMP management team within Cisco but they don't use net-snmp to test with as far as I can tell.  A 30s snmpwalk with net-snmp would pick up lots of these basic errors.

You can try opening a TAC case about it, but my experience with this was that it was a time consuming and painful process to try and have to explain to the engineer why I wanted to use a MIB and not an OID.  And then he didn't really know what to do with it, and couldn't contact anyone to fix it.  I can't remember the outcome but I do remember thinking that it was a huge and painful waste of my time.

All in the name of getting something very basic and low priority fixed.  My strategy now is to maintain an out of tree copy and just remove and edit the mibs by hand when I do an update.

It would be really good if someone from Cisco could contact us here and work to have the mibs fixed up so that everyone including all of Cisco's other customers (who probably also cannot justify spending hours opening TAC cases for this!) could benefit from having a properly functional set of MIBs.

[stuartkendrick]

I opened a TAC case last week, asking how to report MIB file syntax errors.  Here's my understanding of the internal Cisco process.  Take it with salt -- I don't claim to have deep visibility here, and I may have over-interpreted what my TAC engineer told me.

- The development team for each product feature owns the task of pushing MIB updates through a Release Management process, to get those updates out to public / customer consumption.

- Given demanding project priorities, this is a task which sometimes gets left behind:  let's face it, the average customer doesn't know or care about MIB files, those of us who use them are a fairly rarefied bunch, the dev teams give priority to adding new functionality & fixing customer-visible bugs.

- That being said, opening a TAC case helps encourage the development team:  TAC has a way to register "Hey, a customer reported this" to the relevant team.  Does that necessarily change how they prioritize their time?  Definitely helps -- dev teams prioritize customer-visible issues over, say, internal-only issues.  But not a guarantee -- plenty of other bugs will take priority.

Bottom-line:  opening TAC cases helps.  But of course, as you point out, customers like us have to balance the time we spend opening cases with the uncertain impact we are having.  Myself, I intend to continue opening TAC cases, whenever I encounter MIB file syntax errors.

[doug syer]

still has issues:

ive fixed the not accessable stuff by making those read only.

  the rest i may need to manually define its kind of a hot mess.  its a critical mib to have issues..

`cldRegulatoryDomain' cannot be imported from module `CISCO-LWAPP-DOT11-MIB'
 index element `cLApSeIndex' of row `cLApSeClientEntry' must have a range restriction
unknown object identifier label `cldRegulatoryDomain'
/object `cldRegulatoryDomain' of notification `ciscoLwappApIfRegulatoryDomainMismatchNotif' must be a scalar or column
 object `cLApSysMacAddress' of notification `ciscoLwappApRogueApDetected' must not be `not-accessible'
3129: object `cLApEthernetIfSlotId' of notification `ciscoLwappApRogueApDetected' must not be `not-accessible'
3146: object `cLApSysMacAddress' of notification `ciscoLwappApRogueApCleared' must not be `not-accessible'
3146: object `cLApEthernetIfSlotId' of notification `ciscoLwappApRogueApCleared' must not be `not-accessible'
3184: object `cLApSysMacAddress' of notification `ciscoLwappApIfUpNotify' must not be `not-accessible'
3184: object `cLApDot11IfSlotId' of notification `ciscoLwappApIfUpNotify' must not be `not-accessible'
3200: object `cLApSysMacAddress' of notification `ciscoLwappApIfDownNotify' must not be `not-accessible'
3200: object `cLApDot11IfSlotId' of notification `ciscoLwappApIfDownNotify' must not be `not-accessible'

[Adam Armstrong]

I'm also seeing this issue. There are also now a lot of OIDs returned from the latest devices which don't have corresponding MIB entries.

It seems that the MIB versions being presented are not the most recent.

[doug syer]

I do see that varbind on one of the traps.  i dont know if that trap actually works in the real world though ive never seen it, i need to check the capabilities mib...slim chance it may be defined in there

ciscoLwappApIfRegulatoryDomainMismatchNotif NOTIFICATION-TYPE
OBJECTS {
cLApName,
cLApDot11IfType,
cLApDot11IfRegDomain,
cldRegulatoryDomain
}
STATUS current
DESCRIPTION
"This notification is generated if an AP radio's regulatory
domain doesn't match the country the controller is configured
for. Due to the mismatch, the AP will fail to associate with
the controller."
::= { ciscoLwappApMIBNotifs 1 }

[Allen A]

Hello Everyone,

I know it's been quite some time since you opened this and maybe is a little bit too late, however what happens is that the cldRegulatoryDomain object  is not defined in the CISCO-LWAPP-DOT11-MIB anywhere, therefore when loading the CISCO-LWAPP-AP-MIB it throws an error message. This has already been identified and corrected.

The MIB in cisco.com does not have the Object cldRegulatoryDomain which is a pre-requisite by CISCO-LWAPP-AP-MIB to be imported when implemented.

I'm attaching the fixed CISCO-LWAPP-DOT11-MIB here.

Install the attached MIB and then proceed with the CISCO-LWAPP-AP-MIB

About the other MIBs i would think it's a similar issue, but haven't seen any fix for them. 

Hope  it helps.

Allen A.

[stuartkendrick]

Thank you Allen!

[DonaldMcLellan8877]

Hi All

I'm having an issue with the Traps from a FirePower Management Center device,  we're sending snmp v3 traps to our monitoring and event management system. The problem is with the DCEALERT.mib file.  I have to run a sort of compiler over it supplied by BMC which creates map files to reorganise the data in the traps as they arrive for ingestion in the event management system, 

We are already using it for a great number of devices of many different Vendors so I know that the compiler works well. In the mix are Cisco devices too so this problem relates to the newly introduced FMC devices mib file. It appears to ba some sort of formatting issue because the compiler fails as soon as it starts ingesting the DCEALERTS.mib's data. THis is what the error looks like.

"20190823 02:31:16 MC::Base:224 Major - Error at /opt/bmc/tsx/tsagt/pw/server/lib/perl/MA/SnmpTranslator.pm:194 (MA::SnmpTranslator::GetEnterpriseV1): Invalid OID format (<X>.0.<n>) for trap ',sfalertTrap#' (1.3.6.1.4.1.14223.1.1.0)
20190823 02:31:16 MC::Base:224 Major - Error at /opt/bmc/tsx/tsagt/pw/server/lib/perl/MA/SnmpTranslator.pm:315 (MA::SnmpTranslator::GetEnterprises): Cannot get information about oid '1.3.6.1.4.1.1'
Cannot get information about oid '1.3.6.1.4.1.1' at /opt/bmc/tsx/tsagt/pw/server/bin/mib2map.pl line 143."

I haven't seen this issue with anything we've tried before. I'm convinced  sfalertTrap# is the clue, because I couldn't find any reference in the file which correlated with 1.3.6.1.4.1.14223.1.1.0 in the MIB. I was hoping to find a newer or updated version to compare with the one retrieved from the device, but there doesn't appear to be any copies on the CISCO MIB search site.