0

Are there any recommendations and/or best practices when a product has a private (enterprise specific MIB), and the intention is to re-badge the product as if from another manufacturer? That is, a commercial OEM deal occurs. I guess a similar situation arises when a company with a MIB private enterprise number is taken over by another company? Can you replace the stem .1.3.6.1.4.1.x of the OIDs, where x is the private enterprise number, with another company's number? Do you continue with the MIB module unchanged? Do you simply change the contact information contained within the MIB module file?

Thanks in advance for any pointers.

NetHead
  • 71
  • 1
  • 10
  • You need to usually grab the source code, modify, and then build your own copy of its SNMP agent so as to change OIDs. Please collect more information from the vendor. Merely changing the MIB documents is an attempt in vain, and don't waste your time trying that alone. – Lex Li Jul 08 '14 at 12:52

1 Answers1

0

For OEMs, I don't know if there is any best practice. You could do what Lex Li outlines in his comment, modifying both the software and the MIB, as long as you have the kind of OEM deal where you can modify the software. If you don't have that, you probably have no choice but to leave the original MIB untouched, and live with your customers finding out that the product is OEM when they read the MIB. I know my employer sometimes does the latter. If you are the original manufacturer, you have a choice of what to offer your OEM vendor(s), and this will be mostly up to you.

For the other case, where one company buys out another and takes over their product portfolio, there are (at least) two ways to do it. I would say the first one is more advisable, from an engineering perspective at least. A marketing department might say otherwise.

  1. Leave everything as it is. For example, HP bought Compaq 12 years ago , but if you buy an HP server today, they still implement the old Compaq MIBs under .1.3.6.1.4.1.232 (for example CPQRACK-MIB). Probably, it was cheaper to maintain and expand cpq:s extensive MIB tree, than to migrate all their products to the HP enterprise subtree. There are numerous other examples.

  2. Migrate everything to your own enterprise tree. You might skip MIBs that are no longer in use (products discontinued etc). Advantage: Less brand confusion. If products are re-named as part of the buyout, this can be reflected in the new MIBs without violating any RFCs. This approach has the distinct disadvantage of invalidating any existing management solutions designed around the old MIBs. For this reason alone, I would advise against this approach. Nevertheless, it has probably been done.

Jolta
  • 2,620
  • 1
  • 29
  • 42