MIB и продукты OEM

Существуют ли какие-либо рекомендации и/или лучшие практики, когда продукт имеет частную (специальную для предприятия MIB) и намерение состоит в том, чтобы переименовать продукт, как если бы он был от другого производителя? То есть происходит коммерческая OEM-сделка. Я предполагаю, что аналогичная ситуация возникает, когда компания с номером частного предприятия MIB поглощается другой компанией? Можете ли вы заменить основу .1.3.6.1.4.1.x OID, где x — номер частного предприятия, номером другой компании? Вы продолжаете использовать модуль MIB без изменений? Вы просто меняете контактную информацию, содержащуюся в файле модуля MIB?

Заранее спасибо за любые указатели.


snmp mib
person NetHead    schedule 08.07.2014    source источник
comment
Обычно вам нужно взять исходный код, изменить, а затем создать собственную копию своего SNMP-агента, чтобы изменить OID. Пожалуйста, соберите дополнительную информацию у поставщика. Простое изменение документов MIB является тщетной попыткой, и не тратьте время на попытки сделать это в одиночку.   -  person Lex Li    schedule 08.07.2014

Ответы (1)


arrow_upward
0
arrow_downward

Для OEM-производителей я не знаю, есть ли какая-либо передовая практика. Вы можете сделать то, что Лекс Ли описывает в своем комментарии, модифицируя как программное обеспечение, так и MIB, если у вас есть OEM-сделка, по которой вы можете модифицировать программное обеспечение. Если у вас его нет, у вас, вероятно, нет другого выбора, кроме как оставить исходную MIB нетронутой и жить с вашими клиентами, которые узнают, что продукт является OEM, когда они читают MIB. Я знаю, что мой работодатель иногда делает последнее. Если вы являетесь первоначальным производителем, у вас есть выбор, что предложить вашему OEM-поставщику (поставщикам), и это будет в основном зависеть от вас.

В другом случае, когда одна компания выкупает другую и берет на себя их портфель продуктов, есть (по крайней мере) два способа сделать это. Я бы сказал, что первый более целесообразен, по крайней мере, с инженерной точки зрения. Отдел маркетинга может сказать иначе.

  1. Оставьте все как есть. Например, HP купила Compaq 12 лет назад, но если вы покупаете сервер HP сегодня, они по-прежнему реализуют старые MIB Compaq под номером .1.3.6.1.4.1.232 (например, CPQRACK-MIB). Вероятно, было дешевле поддерживать и расширять обширное дерево MIB cpq:, чем мигрировать все их продукты в корпоративное поддерево HP. Есть множество других примеров.

  2. Перенесите все в собственное дерево предприятия. Вы можете пропустить MIB, которые больше не используются (продукты сняты с производства и т. д.). Преимущество: Меньше путаницы с брендом. Если продукты переименовываются в рамках выкупа, это может быть отражено в новых MIB без нарушения каких-либо RFC. Этот подход имеет явный недостаток, заключающийся в том, что любые существующие решения по управлению, разработанные на основе старых MIB, становятся недействительными. Только по этой причине я бы не рекомендовал этот подход. Тем не менее, вероятно, это было сделано.

person Jolta    schedule 09.07.2014