Комментарии 6
"в силу огромного стремления производителей сетевого оборудования быть уникальными" — ничего личного, бизнес. Вендоры по больше части делают эти фишки для галочки — мол у нас есть. Обычно, они дают доступ к какой-либо попсе типа управления вланами. А если речь начинает идти о чем-то сложном класса MLAG Aggregation, то будьте добры спец лицензию и вендоро-зависмую реализацию :)
+6
Не во все сетевые ОС закладывалась возможность использовать 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 модели не полны для вендоров оборудования.
0
А можете кратко и субъективно сравнить protobuf, thrift, asn.1, yaml, if-map в контексте сетей?
а то у меня как-то уже описано всё на yaml, с кучей неявных соглашений,
но подозреваю, что использовать нечто более адаптированое под цели управления сетью будет продуктивнее и удобнее.
а то у меня как-то уже описано всё на yaml, с кучей неявных соглашений,
но подозреваю, что использовать нечто более адаптированое под цели управления сетью будет продуктивнее и удобнее.
0
Не могу. Да и зачем?
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 к сетям имеет мало отношения.
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 к сетям имеет мало отношения.
0
Не хватает комикса
0
Причем заранее понятно, что метаязык никогда не будет проще даже самый вендор-лок конфиги. Так что изучаем еще один язык (на этот раз — язык описания конфига), а потом учимся дебажить, где ошибки в нашей конфиге, где — в работе API железа, где — в самом железе.
Следующим шагом будет тайное знание, что у Cisco надо аттибуты писать так, у Juniper — вот в таком порядке, а у кривого D-Link-овского стыка API с железкой нужно всегда указывать значения всех, даже ненужных в команде аттрибутов, а то китайские программеры так написали парсер.
Следующим шагом будет тайное знание, что у Cisco надо аттибуты писать так, у Juniper — вот в таком порядке, а у кривого D-Link-овского стыка API с железкой нужно всегда указывать значения всех, даже ненужных в команде аттрибутов, а то китайские программеры так написали парсер.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OpenConfig — стандартизированный подход к настройке сетевого оборудования