Pull to refresh

Comments 6

"в силу огромного стремления производителей сетевого оборудования быть уникальными" — ничего личного, бизнес. Вендоры по больше части делают эти фишки для галочки — мол у нас есть. Обычно, они дают доступ к какой-либо попсе типа управления вланами. А если речь начинает идти о чем-то сложном класса MLAG Aggregation, то будьте добры спец лицензию и вендоро-зависмую реализацию :)
Не во все сетевые ОС закладывалась возможность использовать API, и производителям бывает непросто встроить их поддержку в свои продукты.

Ага. А OpenConfig будет легче встроить, чем какой-то свой API? Я думаю, что если свой API не смогла компания осилить, то куда же ей до Openconfig-а.

Если на каждой из них нужно настроить одну и ту же функцию, несложно догадаться, что хотелось бы, чтобы она везде настраивалась одинаково!

А то что функция имеет разные фичи на разных девайсах — это как?
А то что концепции одной функции у разных вендоров разные — как это уместить в одной модели?

На заре своей деятельности «неформальная рабочая группа» OpenConfig весьма продуктивно работала, создавая модели для BGP, MPLS и управления интерфейсами.

У меня есть подозрение что неформальная группа стартовала с использования наработок Google-а, который, как раз, эту группу (OpenConfig) и двигает: https://www.nanog.org/sites/default/files//meetings/NANOG64/1011/20150604_George_Sdn_In_The_v1.pdf

Например, для компании Juniper поддержка моделей IETF и OpenConfig не составит труда.
Составит труд. Не все параметры из моделей juniper-а есть в модели OpenConfig-а и наоборот. Как тут быть? Пойти по пути расширения стандартной модели своими проприетарными фичами? Тогда получим то, что имеем сейчас — каждый вендор будет иметь свой личный зоопарк из моделей.

Потребитель, который может заплатить, как правило, получает, чего хочет.

А хочет ли?

Когда стандартные сетевые модели станут встречаться повсеместно, мир откроется для разработки инструментария, платформ оркестровки, ПО для мониторинга и SDN контроллеров, и на рынке появятся прекрасные инструменты для конфигурирования и отчетности.

А сейчас что мешает?

то сейчас многие производители активно добавляют поддержку различных интерфейсов прикладного программирования (OpenFlow, OpenStack, JSON, XML, NETCONF/YANG и пр.).

Извините, но как все эти слова в скобках связаны друг с другом?

Мне лично кажется, что сайту PacketPushers занесли за эту статью.

По моему опыту работы с YANG, yang хорош для задания своих моделей и для генерации кода на базе этих моделей. То есть еще один такой protobuf, thrift, asn.1. Зачем нужно было еще один выдумывать — видимо для поднятия денег.

Существующие модели для YANG-а сложно использовать в реальных проектах.
Во-первых YANG модели никто не поддерживает.
Во-вторых YANG модели не полны для вендоров оборудования.
А можете кратко и субъективно сравнить protobuf, thrift, asn.1, yaml, if-map в контексте сетей?
а то у меня как-то уже описано всё на yaml, с кучей неявных соглашений,
но подозреваю, что использовать нечто более адаптированое под цели управления сетью будет продуктивнее и удобнее.
Не могу. Да и зачем?
YANG — это способ описания схемы данных. Точка.
На нем вы можете описать свою модель. А данные положить во что угодно, куда можно уложить иерархическую схему. Например gobgp описывает свою конфигурацию с помощью расширения OpenConfig модели BGP своими значениями. А потом данные хранит в yaml или toml: https://github.com/osrg/gobgp/tree/master/tools/pyang_plugins

У вас в yaml описаны данные. Можете задать их схему на YANG. Можете на чем угодно другом. Удобный инструмент работы с YANG — pyang. Является стандартом де факто в IETF и OpenConfig. Google пытается пилить goyang: https://github.com/openconfig/goyang, но пока далеко не ушли.

Попробуйте использовать YANG для своих целей, посмотрите, насколько он вам поможет своей более "сетевой" природой. Там сетевые только модели, описанные на YANG, но сам YANG к сетям имеет мало отношения.
Причем заранее понятно, что метаязык никогда не будет проще даже самый вендор-лок конфиги. Так что изучаем еще один язык (на этот раз — язык описания конфига), а потом учимся дебажить, где ошибки в нашей конфиге, где — в работе API железа, где — в самом железе.

Следующим шагом будет тайное знание, что у Cisco надо аттибуты писать так, у Juniper — вот в таком порядке, а у кривого D-Link-овского стыка API с железкой нужно всегда указывать значения всех, даже ненужных в команде аттрибутов, а то китайские программеры так написали парсер.
Sign up to leave a comment.