Comments 9
А вы тоже заметили, как штаны подворачиваются??
Очень крутая работа, уважуха,
кстати упомянутый gnmic очень хорош в --prompt режиме для парсинга YANG моделей
вот тут у них в доке https://gnmic.kmrd.dev/user_guide/prompt_suggestions/
И еще у упомянутого Романа Додина, есть отдельная утилита чтоб из моделей готовые xpath доставать https://github.com/hellt/yangpath, подозреваю этот его код потом вошел в gnmic
А из этих path потом простой рекурсивной функцией можно крафтить XML-ки на лету не привлекая джинжа програмистов
Всё это безумие упирается в вендоров. Вендоры не хотят сами (по своей воле) реализовывать интероперабельность. Их заставили реализовать её на уровне сети (так, что циска с аристой может держать bgp сессию, а джуник понимает arp запрос от экстрима), но конфигурация - это интимное. Наличие общей системы конфигурации, в которой железо "просто работает" означает, что если вынуть железо Ценного Вендора за $30k и заменить его Мерзким Конкурентом за $20k, то всё продолжит работать, а Ценный Вендор очевидно потеряет в продажах. Поскольку Ценный Вендор хочет оставаться ценным, то он имеет нулевое желание реализовывать модель управления, которая сделает жизнь Мерзкого Конкурента легче. Крупный Покупатель может заставить Ценного Вендора реализовать то, что ему нужно, но даже Крупный Покупатель использует ну процентов 20 из фич вендора, а оставшиеся фичи будут ... работать через cli.
Описание же общей модели (хотя бы уровня "в каком месте вешается IP на транк-вилане") опасно приближает Ценного Вендора к коммодити с Мерзким Конкурентом.
В целом, чем более серьёзные фичи, тем хуже они укладываются в простые модели. Все вендоры более-менее имеют одинаковый интерфейс для "вкл/выкл" физический порт. А вот если мы хотим сделать unnumbered маршрутизацию в оверлейную сеть между vlan'ом поверх бонда и vxlan'ом, терминирующимся на кластерном линке... В каком именно месте там конфигурируются IP - один вендор знает.
если ценный вендор это циска, то они декларируют поддержку в своем оборудовании и oc и ietf модели и более того заявляют что такое заигрывание с опенконфигом это их конкурентное преимущество над "мерзкими конкурентами"
причем для ios-xe поддержка сразу из коробки, что немного странно потому что ios-xe чисто ентерпрайзное железо, а ентерпрайзу и в CLI норм и все эти интеропы скорей нужны для датацентров (нексусы) и опсосов (ios-xr)
впрочем для поддержки нексусами опенконфига достаточно рпм-ку скачать в свич и поставить отсюда https://devhub.cisco.com/artifactory/open-nxos-agents/
И учитывая что там есть сборки для каждой версии nxos обвинять циску в игнорировании открытых моделей не получаетсяА вот если мы хотим сделать unnumbered маршрутизацию в оверлейную сеть
между vlan'ом поверх бонда и vxlan'ом, терминирующимся на кластерном
линке.
Все получится. Сложность задачи и сложность конфигурации находятся в разных плоскостях. Это нам мозгом сложно пазл сложить из нагромождений конфига, а у жедезки мозга нет. Она не заморачивается а просто раскатывает полученную XML-ку по внутреннему дереву предварительно отвалидировав по внутреннему же XSD.
Инженерам сложнее, надо дезинтегрировать задачу на все эти отдельные сущности unumbered, vlan, lacp, vxlan, bgp, благо они все давно в опенконфигах описаны, и шаг за шагом скрафтить нужную XML-ку
Нет, не циска. Совсем другой вендор, подсказка - "без коммитов" от слова "совсем".
Сложность, про которую я говорю, состоит в том, что у каждой железки это будет другая модель с другими словами и отношениями между сущностями. Где-то должен быть софт, который эту модель с другой моделью другого вендора объединит, и выдаст наружу абстракцию, в которой оба вендоры "одинаковы".
Огромное спасибо за проделанный труд! Великолепная статья.
Для меня, по окончании её прочтения и вкупе с собственной рефлексией остается "осадочек" - просто потому что есть явное осознание, что в массы (small/midlle enterprise / SP) это двигаться если и будет - то крайне медленно (а возможно и вовсе не будет - ведь нет того самого "бизнес-драйвера"). NETCONF/YANG-стандартизация при выходе за рамки настройки чего-то простого, на мой взгляд, выглядят особенно утопично для самих вендоров (не смогут зарабатывать на "софте", а смогут только на железе).
И, если разложить по полкам, то мы имеем:
Сети гиперскейлеров с десятками/сотнями ДЦ (десятками/сотнями тысяч свитчей и прочего AО): для них "автоматизация" - это вопрос выживания и конкуренции. При таких масштабах есть и тот самый "бизнес-драйвер" =-> уменьшение Time-to-Market и уменьшение затрат на Ops сетей (как минимум в виду не раздувания персонала).
Под этими задачами пытаются "прощупывать" всякие решения - есть и попытки развития Open NOS и WhiteBox-коробок, попытки совместить управление коробками разных вендоров через NETCONF/YANG (вместо десятков тулзов вендоров, которым еще и астрономические суммы за софт платить придется).Сети Провайдеров с "разношерстными" вендорами и десятками тысяч коробок : для них NETCONF/YANG-стандартизация была бы выгодна - по причине экономии и на железе и на Ops, но....
Тут есть понимание, что не все провайдеры "одинаковы" - но для многих в РФ это просто нереально по причине того, что:
1. тех.стек "устоялся" (и никаким NETCONF там не пахнет в виду legacy-коробок, "самописные" костыли - оставим за рамками)
2. инженерная сила (сетевиков) относительно "дешева".
Сомневаюсь, что и в остальном мире (возможно, кроме Китая) подход иной - для рентабельности провайдера необходимо максимально выжимать все "соки" из CAPEX'а на стройку (которая зачастую была когда NETCONF/YANG еще и в проекте не было).
Некоторые провайдеры, конечно, стараются быть не "просто трубой". Но, будем честны, эти старания в основном направлены на предоставление каких-то услуг (НЕ ТРАНСПОРТНЫХ!), которые базируются в каких-то ЦОДах. А про сети ЦОДов для негиперскейлеров - см. нижеСети Small/Middle Enterprise (от 0 до 10 ДЦ, региональные WAN-сети и прочее) : автоматизация (через NETCONF и прочие gNMI) там вовсе не обязательна. Хватает и более "грубых" инструментов - самописных скриптов/Ansible/Salt/etс.. Да есть и разновендорность - но в виду относительно небольших масштабов нет критической необходимости заморачиваться с NETCONF - разве что инженерное любопытство может заставить разобраться в теме. При этом попытки имплементации могут разбиться о действительность, в которой БИЗНЕС не видит причин для изменения текущей парадигмы.
И если уж необходима орекстрация и автоматизация, то зачастую БИЗНЕСУ легче купить решение от какого-то одного вендора (благо они есть) - и отдавать вендору денег за поддержку "софтварной" части этого решения. Ну а инженерам просто придется освоить то решение, которое дал вендор - оно может быть вполне на модном NETCONF, но в рамках работы с одним вендором:)
Мы идем по пути эволюции, но не чистой, а "скорректированой" по коммерческой составляющей (впрочем, в технологиях, так почти везде).
На мой взгляд, единственный фактор буста в сложившейся коньюнктуре для NETCONF/YANG - это дальнейшее развитие NOS с открытым исходным кодом (допиливание фич, OC и драйверов для работы с разными платформами и т.п) && развитие White-box решений (для масс-маркета Enterprise/SP, а не только DC). И да (ура!) - вот тогда это и будет управляться "чисто как сервера" сейчас - и тогда нужны будут NetOps в дополнение к DevOps (ну или DevOps'ам придется освоить еще одну компетенцию:))
Все вышеприведенное - это мое субъективное мнение, буду рад услышать другие взгляды на происходящее в индустрии относительно направления автоматизации!
Еще раз спасибо за проделанную работу - было очень интересно читать!
На самом деле мне близки вещи, которые вы описали. И согласен почти со всем.
Однако для того, чтобы что-то случилось, об этом нужно говорить. Говорить нужно много и при любой возможности, прожужжать всем уши и стучаться через все каналы.
И тогда, после того, как каждый будет знать, что есть NETCONF, появится и запрос.
Это мне так кажется. Возможно, ошибаюсь, потому что тот же gRPC элементарно решал насущные задачи разработчиков, поэтому стал стандартом де-факто для межсервисного взаимодействия.
Возможно, новые интерфейсы для сети не решают их. Или не делают этого пока - спрос ещё не созрел.
Но, я уверен, что как и со многими другими технологиями (тот же gRPC, или k8s, Go, React, OSquery, GraphQL) они сначала зарождаются в недрах компаний, для которых это вопрос выживания, а потом становятся распространены в индустрии, то же самое произойдёт (уже происходит) с NETCONF/YANG, gNMI и whitebox'ами.
Ох, очень надеюсь, что все это не останется технологией для "гиперскейла", а выйдет наружу.
В конце-концов мы можем быть подвержены "ошибке выжившего" - ведь на слуху и в ПРОДЕ сейчас действительно много инструментов, которые начинались в "гиперскейлах", но никто не говорит о тулзах, которые были сделаны\открыты "гигантами", но так и не нашли применения в других секторах. Это наверное тема отдельного академического исследования:)
Так же соглашусь с позицией о том, что для того, чтобы что-то изменилось - надо об этом говорить и популяризовать. А еще крайне желательно говорить, показывая use-case для реального применения (желательно в условиях ограниченного бюджета --> и вот он - "бизнес-драйвер" для small/medium-enterprise для Green Field проектов :))
Так же позволю себе поделиться ссылкой на то, что было 8 лет назад:
https://habr.com/ru/company/etegro/blog/227897/
Уже тогда некоторые "держали нос по ветру" и видели смысл заморачиваться с популяризацией...но только при условии продажи довольно дорогого железа к NOS :)
Прошло 8 лет, стал популярен докер/кубер/CI/CD и прочие DevOps-инструменты для IaaC и...
Я не так давно самостоятельно пытался найти и прощупать тот самый кейс, когда можно взять относительно дешевый L2(L3)-коммутатор типа "пицца-бокс" с ONIE :
стоимостью на уровне D-link, но лучше - ниже -> ниша для ISP;
или стоимостью ниже или паритетное Huawei/Cisco (конечно с учетом скидок от GPL которые дают/давали вендора) -> для Small/Medium Enterprise
стоимость обслуживания сети при этом не должна разительно вырасти (Ops), лучше конечно (утрируя, и как бы страшно это не звучало!) - "чтобы legacy-сетевики были не нужны", а всем ведали DevOps или небольшой отдел NetOps.
Так же внезапно оказывается, что в условиях санкций и ограничений - "драйвер" для бизнеса (особенно Medium/Large) вполне может быть -> т.к если официальной поддержки софта от вендора нет - то может быть рационально инвестировать в развитие собственного инженерного потенциала - развивая и допиливая открытые NOS'ы. Или этим мог бы заняться некий консолидированный "стартап" в РФ, чтобы потом монетизировать все это через поддержку софта (типа как RedHat и Cumulus) - идея не нова... впрочем для того, чтобы пазл сошелся - должен быть масштаб рынка как у RedHat/Cumulus, имхо - весь мир :)
А если этого нет этого рынка, то это либо должно быть сделано политическим усилием (и все-таки с перспективой выхода на международные рынки), либо... у нас есть уже вендоры "второй/третьей" линии (с ТОРП), которые пилят свой проприетарный управляющий софт, дергая за ниточки Broadcom/Realtek SDK - пользуйтесь ими на здоровье :)
В итоге - я так и не смог нащупать данный кейс, потому что не увидел более дешевого или паритетного по ценам железа (c ONIE) с вендорами "второй/третьей" линии. А для "первой" вроде как есть сдерживающий фактор - total cost of ownership (т.е легче купить оборудование "второй" линии и уже каким-никаким софтом на поддержке, чем покупать голую c ONIE и допиливать напильником самому - все же ПРОД!) - я так и не смог понять тот баланс, где начинается реальный буст для новых технологий, а где выгодно использовать то, что есть. Sad story, but true...!
Если у кого-то есть такие use-case или хотя бы что-то отдаленно напоминающее success story не у гиперскейлеров - то было бы здорово ознакомиться с ними.
АДСМ6. Интерфейсы взаимодействия с сетевыми устройствами