【问题标题】:MIBs and OEM productsMIB 和 OEM 产品
【发布时间】:2014-07-08 07:22:35
【问题描述】:

当产品具有私有(企业特定 MIB)并且打算重新标记产品时,是否有任何建议和/或最佳做法,就好像来自其他制造商一样?也就是说,发生了商业 OEM 交易。我想当一家拥有MIB私营企业编号的公司被另一家公司接管时,也会出现类似的情况?您能否将 OID 的主干 .1.3.6.1.4.1.x(其中 x 是私营企业编号)替换为另一家公司的编号?您是否继续保持 MIB 模块不变?您是否只是更改 MIB 模块文件中包含的联系信息?

提前感谢您的任何指点。

【问题讨论】:

  • 您通常需要获取源代码,修改,然后构建自己的 SNMP 代理副本,以更改 OID。请从供应商处收集更多信息。仅仅更改 MIB 文档是徒劳的尝试,不要浪费时间单独尝试。

标签: snmp mib


【解决方案1】:

对于 OEM,我不知道是否有任何最佳做法。您可以按照 Lex Li 在他的评论中概述的方式修改软件和 MIB,只要您有可以修改软件的 OEM 协议。如果您没有这些,您可能别无选择,只能保持原始 MIB 不变,并与您的客户一起生活,当他们阅读 MIB 时发现该产品是 OEM。我知道我的雇主有时会做后者。 如果您是原始制造商,您可以选择为您的 OEM 供应商提供什么,这主要取决于您。

对于另一种情况,即一家公司收购另一家公司并接管其产品组合,有(至少)两种方法可以做到这一点。我会说第一个更可取,至少从工程角度来看。营销部门可能会另说。

  1. 保持原样。例如,HP 在 12 年前购买了 Compaq,但如果您今天购买 HP 服务器,他们仍然在 .1.3.6.1.4.1.232 下实施旧的 Compaq MIB(例如 CPQRACK-MIB)。维护和扩展 cpq:s 广泛的 MIB 树可能比将其所有产品迁移到 HP 企业子树更便宜。还有很多其他的例子。

  2. 将所有内容迁移到您自己的企业树中。您可以跳过不再使用的 MIB(产品停产等)。优点:减少品牌混淆。如果产品被重新命名为买断的一部分,这可以反映在新的 MIB 中,而不会违反任何 RFC。 这种方法的明显缺点是使围绕旧 MIB 设计的任何现有管理解决方案无效。仅出于这个原因,我建议不要使用这种方法。尽管如此,它可能已经完成了。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-09-13
    • 1970-01-01
    • 2019-10-07
    • 2015-02-01
    • 2023-03-03
    • 1970-01-01
    • 2015-09-23
    • 1970-01-01
    相关资源
    最近更新 更多