cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Compile our own MIB database.

Compile our own MIB database.

Too many MIBS to keep up with, and too many issues with SW's management of them.

Years back, I submitted everything we had, added new ones as necessary.

At a certain point, a year or two ago, Destiny decided to clean out the MIB db, and key things were lost, deemed duplicate,

when they certainly weren't.  It was a travesty that made me stop using MIB updates from SW at all, and I haven't updated since

my last good copy.

This is also a drag, because there are always new pieces, and new requirements.  The vast bulk of SW customers may not need this feature,

but anyone managing more than 100 nodes has probably run into issues.  Anyone new to the product with carrier gear would absolutely love it,

and it was mentioned in other feature request threads.  I think it's been talked about for years.  It can't be that difficult to package this thing up so

it can be installed and used, even if it's rough at first, because the vast majority of people who are going to want it, will be able to handle a little complexity.

This has long been an outstanding issue.  I could tail onto this, no multiple copies of the MIB database, but I don't know if that's still an issue.

I know .5GB of MIBS.cfg having to get dropped in 3 places back in the day was a bit of an issue.

Peter

33 Comments
Level 12

Nice to know there's 19 folks at least interested in seeing some action on this.

Anyone have any comments to attempt to help push this along?  Additions?

Level 17

even if you created a folder for "custom MIBs" that people could drop their needed files into and SW would occasionally parse through to import or even a script/button for on-demand parsing.

Level 12

Apparently, I accidentally created a duplicate feature request that can hopefully be closed.

In that one, I stated what I will re-iterate here:

Less "rah rah rah" and fluff, and more critical functionality addressed, please!  I'm so sick of seeing all these cosmetic changelogs!

Peter

Level 12

Also, I'd recommend that this be an option, either use the stock one or roll your own, but using the stock one and being able to layer in custom ones would be great, just much harder to implement.  Initially the either/or approach would be good.

Peter

Level 11

I will give this a +1 to be honest..

But to be fair if Solarwinds Support are quick at turning around updates to their MIB file that you download through the customer portal I dont really see a problem in the traditional process..

Level 12

Here's the problem with the traditional process:

1)  MIB DB size limitation of 512MB.  This means that SW periodically has to pick what MIBs to remove in order to make space for more.  Many implementations of various pieces of equipment are incomplete or made incomplete by this process.  The first time this happened was several years ago, after I had spent 2 years sending in MIBs.

2)  The needs of the many outweigh the needs of the few, which is a right and proper philosophy for a vendor-managed MIB DB, unfortunately, that doesn't fit the "I have a huge telecom network I need to manage" use case.  Many pieces of transport and telephony equipment (including needing to have multiple software versions of 2MB enterprise MIBs) unfortunately get dropped, because they are not the mainstream Cisco switches and wireless devices.  In fact, I need a total of maybe 10 or 15 different Cisco devices supported, unfortunately they are things like AS5300-5350-5400 gateways, COC-12 cards on 76xx routers, Juniper equivilents, as well as SRX240 devices (on my specific SW version), Acme Packet Net-Net products (and the EMS), Turin (aka Force10/Dell/someone else now) transport DACS gear, ancient DS3 muxes, and of course various IAD's that do voice, data, or both including DSP status, etc which is all pollable by SNMP.  I would be able, with this feature request, to handle *my* precise, environment.

3)  I currently have a vbscript variable based work around that poll a table sitting on the same MS SQL server that Orion uses to translate traps for 1 piece of equipment, but it's overly resource heavy to roll out across the entire network.  It's very much *not* pretty but functional for at least 1 device that spews hundreds of traps per minute.  It's obviously not scalable though.

Peter

MVP
MVP

Re 1) My MIB DB is significantly larger than 512 MB. On my prod server (NPM, NTA, VNQM, IPAM) the MIB database is 1.03 GB (last modified 29/04/2013).  I installed the NPM 10.5 eval on a lab server and it is 589 MB (last modified 27/09/2012).

Level 12

Hmm... I haven't looked in forever, but I have not knowingly replaced my MIB DB in over 3 years.

That does lend more credence to the idea of going back to the submit it to SW and they can manage it, but the question is, will they fold in all my old crusty mibs anymore?  What about the ones for EOL HW that still lives?  I still stand behind this feature request, but that definitely does take some of the pain out not getting it, and I'd rather see the dev resources on more painful issues if it's really at a point where those limitations no longer exist.  I could be convinced to live with it if it works and has all my stuff, even if I have to re-transmit it to SW, if it's just one final time, I could easily live with that.

Peter

MVP
MVP

Oh I agree that it would be easier to be able to manage your own MIBs or at least have a custom MIB area that SolarWinds could load in addition to the main one. I just happened to notice the 1 GB MIB on my server the other day and was surprised as a year ago it was 512 MB. Could also just be some bug on my server.

Level 7

Agreed.  Custom MIB area seperate from Solarwinds database would be extremely helpful so that we can put our own or manufactures MIBs in to monitor devices more quickly.  Solarwinds is too SLOW to keep up and I don't have the time to wait on them.