Хотим поделиться с вами вольным переводом статьи с сайта Packet Pushers о сложностях конфигурирования мультивендорных сетей. В первую очередь, с ними сталкиваются операторы связи. По мере того, как провайдер развивается (в т. ч. поглощая других операторов), его сеть растет и превращается в сложную экосистему различного оборудования. В небольших сетях эта проблема, как правило, стоит не так остро. Что, впрочем, обусловлено ею же — компании стараются без веских на то причин не закупать в свою сеть железо разных производителей. Сложности настройки здесь заставляют тяготеть к моновендорности.

Дилемма оператора

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

При управлении через командную строку (Command Line Interface — CLI), сетевые операторы сталкиваются со значительными отличиями в её синтаксисе на оборудовании разных производителей. Например, команды, которыми протокол BGP настраивается на устройстве Cisco под управлением операционной системы IOS, не подойдут для выполнения той же задачи на устройстве Juniper под управлением JUNOS. Переход с командной строки на конфигурирование оборудования через интерфейсы прикладного программирования (API) не решает проблему. Интерфейсы, предлагаемые производителями сетевого оборудования, по реализации и функциональности отличаются друг от друга не меньше CLI. Отчасти это обусловлено спецификой сетевых операционных систем. Не во все сетевые ОС закладывалась возможность использовать API, и производителям бывает непросто встроить их поддержку в свои продукты.

Конфигурационные модели

Один из вариантов реализации программной настройки сетевого оборудования – конфигурационные модели. Модель данных определяет структуру, синтаксис и семантику данных, которые мы загружаем на сетевое оборудование. При их передаче, в связке с моделью данных действует протокол, который определяет их кодирование и сам механизм передачи на устройство. Другими словами, модель определяет правила, с помощью которых мы задаем параметры конфигурации сетевого оборудования. А транспортный протокол передаёт эти данные на оборудование. Конфигурационную модель можно сравнить с протоколом SNMP, который изначально был разработан для управления сетевыми устройствами, но в силу ряда причин используется в основном для мониторинга. — прим. ред.

Для нас, привыкших рассматривать всякое сетевое устройство, исходя из интерфейса его командной строки, «модель» представляется в виде строк конфигурации. К примеру, «interface gigabitethernet 0/1» или «router bgp 65432» открывает пользователю Cisco IOS режим конфигурации Ethernet-интерфейса или процесса BGP-маршрутизации. А транспортом в этом случае выступает протокол SSH.

Многие понимают, что будущее конфигурирования сетевых устройств остаётся за интерфейсами прикладного программирования. Но отойдя от командной строки, мы не ушли от главной проблемы: унификация настройки оборудования теперь затрудняется не синтаксисом командной строки, а моделями данных для протоколов вроде NETCONF, созданными на базе описательных языков моделирования. Эти модели часто пишут на базе языка YANG и они, как и синтаксис командной строки, сильно разнятся от производителя к производителю. В результате, пользователи остаются всё с той же проблемой: на разном железе процесс выполнения одной и той же задачи по-прежнему отличается.

Разнообразие — совсем не изюминка

Индустрия сталкивается с проблемой: мы хотим автоматизировать процесс конфигурирования сети, но не можем предугадать, какие модели и интерфейсы для этого понадобятся. Звучит очень знакомо. Вспомним о протоколе SNMP. SNMP — общепринятый стандарт. Все сетевые устройства поддерживают те или иные элементы баз MIB. Тем не менее, наиболее важные параметры уникальны для каждого производителя оборудования и требуют использования специфичных баз MIB.

Сможем ли мы облегчить этот конфигурационный кошмар, перейдя с CLI и SNMP на NETCONF (или любой другой способ передачи конфигурации) с YANG-моделями?

Производители, естественно, будут отстаивать уникальность своих решений, а также абсолютную необходимость использования моделей, которые соответствуют их конкретным возможностям. И их можно понять. Было бы несправедливо критиковать производителей за их стремление отличаться от конкурентов.

В свою очередь, сетевые операторы имеют такое же право отстаивать идею, что сети есть сети. BGP это BGP, ISIS это ISIS, OSPF это OSPF, а интерфейс Ethernet (по большей части) это интерфейс Ethernet, и т.д. И какая разница, конфигурируем мы железку Cisco, Juniper, Brocade или что-то ещё. Если на каждой из них нужно настроить одну и ту же функцию, несложно догадаться, что хотелось бы, чтобы она везде настраивалась одинаково! Как можно автоматизировать конфигурирование сети, когда, стоит нам только отвернуться, как где-то уже нужно подправить скрипт, добавить модуль, подождать, пока инструмент автоматизации получит патч от производителя, или потребуются ещё какие-нибудь пляски с бубном?

OpenConfig и IETF приходят к стандартным сетевым моделям

Сложившаяся ситуация беспокоит не только автора. У IETF есть несколько проектов разной степени завершенности, направленных на разработку стандартных сетевых моделей на базе YANG. К примеру: модель для управления сетевыми интерфейсами RFC7223, модель для инвентаризации и управления RFC7317, модель для настройки протокола SNMP RFC7407, а также модель для настройки протокола OSPF. Но для кого-то работа IETF продвигается слишком медленно, а кому-то просто не подходят модели, которые они предлагают.

В связи с этим, несколько крупных компаний решили приблизить переход на стандартные сетевые модели, организовав проект OpenConfig. На главной странице OpenConfig пишет о себе так:

«OpenConfig — это неформальная рабочая группа операторов сетей, объединенных общей целью — перевести сети на более динамичную программируемую инфраструктуру путем внедрения принципов программно-определяемых сетей, таких как декларативная конфигурация и управление на основе моделей. Основное направление нашей работы — разработка единых моделей данных для конфигурации и управления, поддержка которых изначально встроена в программные и аппаратные платформы различных производителей оборудования»

Кто же эти компании? По состоянию на январь 2016, среди участников на странице OpenConfig числились: Google, AT&T, British Telecom, Microsoft, Facebook, Comcast, Verizon, Level3, Cox Communications, Yahoo!, Apple, Jive Communications, Deutsche Telekom/TeraStream, и Bell Canada. Другими словами, КРУПНЫЕ поставщики услуг с огромными сетями и центрами обработки данных, которым нужно поддерживать постоянный рост и обеспечивать динамичные изменения в своих сетях, желательно, с минимизацией различных препятствий в их работе.

На заре своей деятельности «неформальная рабочая группа» OpenConfig весьма продуктивно работала, создавая модели для BGP, MPLS и управления интерфейсами. Сейчас в доступе есть разные модели (например, модель для сетевой телеметрии). Все они опубликованы на Github, и быстро эволюционируют, ведь именно для быстрой эволюции OpenConfig и создавался. На странице FAQ OpenConfig пишут: «На данный момент формального руководства у проекта нет. Мы полагаемся на то, что у участников здесь общие цели и видение, их действия прозрачны и по общим вопросам они стараются поддерживать согласие».

Конечно, если начинать размышлять о проекте вроде OpenConfig, обнаружатся два главных повода для беспокойства:

1. Будут ли производители сетевого оборудования поддерживать OpenConfig?
2. Не пренебрегает ли OpenConfig стандартами IETF?

Рассмотрим первый — поддержку производителями. Для производителей сетевого оборудования главный вопрос здесь состоит в том, насколько сложно им будет приспособить существующие сетевые ОС к работе на основе моделей. Например, для компании Juniper поддержка моделей IETF и OpenConfig не составит труда. JUNOS и так, по сути своей, управляется моделями. К тому же, Juniper намекает (к сожалению, ссылок на эти намеки автор не дает — прим. ред.), что поддержка OpenConfig будет в ближайших версиях JUNOS (возможно даже в 16.1). Компания Cisco анонсировала поддержку OpenConfig для IOS-XR (NCS, ASR, CRS, XR) ещё в ноябре 2015 (уже доступна поддержка двух моделей OpenConfig — BGP и Route Policy — прим. ред.).

Добавят ли другие производители поддержку моделей OpenConfig? Время покажет. Но есть сильные подозрения, что так и будет. Вспомните, кто стоит за этой инициативой. Деньги в сетевой индустрии имеют право голоса. Потребитель, который может заплатить, как правило, получает, чего хочет.

Как же IETF? OpenConfig идёт своей дорогой? И да, и нет. Всё несколько сложнее. Проект OpenConfig начинался отчасти как реакция на слабо упорядоченную и неспешную работу IETF. Тем не менее, OpenConfig сотрудничает с IETF, помогая им развивать различные стандарты. На странице годового отчета OpenConfig за 2015 внизу перечислены проекты, созданные рабочей группой OpenConfig для IETF. Так что, хоть OpenConfig и не желает ждать, пока IETF разберется со своими моделями, он признаёт важность IETF и даже привносит собственный вклад в их дело.

Что может дать OpenConfig?

Основная идея в том, что OpenConfig ориентируется только на модели, уделяя меньшее внимание законченным API, включающим в себя как модель, так и транспорт (подробнее вопрос раскрывается в статье Джейсона Эделмана). Ведь наша главная цель — достичь целостности и предсказуемости модели на всех сетевых устройствах. Инструменты (транспорт), которыми мы загружаем модели на оборудование, важны, но в их случае проблема выбора и унификации стоит не так остро, как с представлением и моделированием данных. По большому счёту, нам всё равно, как данные были загружены. Но очень важно, чтобы они были представлены в нужном нам формате — чтобы мы могли их понять, то есть, чтобы наши инструменты легко могли их проанализировать и работать с ними.

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

Ethan Banks, январь 2016


Вопрос наличия стандартных подходов для конфигурирования сетевого оборудования разных производителей возник давным-давно. Тот же протокол SNMP был одной из попыток его решить. Он оставался нерешённым так долго, что к ситуации все вроде как даже привыкли. Появление программно-определяемых сетей подняло его на поверхность в очередной раз. Идея подключения к контроллеру любого сетевого оборудования предполагает наличие стандартных средств общения между контроллером и устройством. Параллельно с этим возникла необходимость в средствах обеспечения автоматизации конфигурирования сетей — их программируемости. Если раньше для настройки сетевого оборудования чаще всего использовались командная строка и Web-интерфейс, то сейчас многие производители активно добавляют поддержку различных интерфейсов прикладного программирования (OpenFlow, OpenStack, JSON, XML, NETCONF/YANG и пр.). Причём даже в рамках одного вендора нам предлагают целый букет таких средств. В связи с этим, идея OpenConfig вполне здравая и уместная в плане времени появления.

Статья получилась, на наш взгляд, чуточку утопической в силу огромного стремления производителей сетевого оборудования быть уникальными. Согласившись на полноценную стандартизацию, они рискуют превратить свои устройства в безликие коробки. Скорее всего, поддержка OpenConfig ограничится программированием определённых функций. Как обычно, время всё расставит на свои места.