NETCONF

Сытые 0-е и по ныне

Если вам по какой-то причине кажется, что стандарты рождаются где-то в недрах институтов, оторванных от жизни, то послушайте вот эту историю. Скорбно при этом помним про ISO.

В 1996 выходец из Ксерокса Прадип Синдху и Скот Кринс из StrataCom, купленной Циской, основали Juniper Networks. Идея создания мощного пакетного маршрутизатора пришла в голову Синдху, и он стал CTO компании, а второго наняли на роль CEO.

Juniper M40. Источник

Вместе они создали легендарный М40 и лучший в мире интерфейс командной строки. До сих пор никто не сделал ничего лучшего - все только повторяют.

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

Так вот, их CLI и способ взаимодействия его с системой оказался настолько естественным и удачным, что его и положили в основу стандарта NETCONF в 2006-м году. Не без участия Juniper Networks, конечно же, появился RFC4741. Будем честны, один только джунипер там и постарался в практической части. И то тут, то там будут проскакивать его куски, начиная с set и заканчивая candidate config.

Вот как он был определён в нулевых:

Abstract
The Network Configuration Protocol (NETCONF) defined in this document
provides mechanisms to install, manipulate, and delete the
configuration of network devices.  It uses an Extensible Markup
Language (XML)-based data encoding for the configuration data as well
as the protocol messages.  The NETCONF protocol operations are
realized on top of a simple Remote Procedure Call (RPC) layer.

И определение с тех пор не менялось - вся суть NETCONF в этом параграфе.

Но как так получилось, с чего началось? Да с того, что в начале 2000-х IAB проснулся в одно недоброе утро и осознал, что все планы по CMIP мир провалил, SNMP прорастил свои корни глубоко и перестал быть Simple, никто из вендоров так и не реализовал на 100% его поддержку, в самой аббревиатуре SNMP «M» вместо «Management» стала обозначать «Monitoring», и к тому же единой модели данных конфигурации не получилось. Хуже того - появился этот выскочка Juniper, который везде суёт свой нос.

В общем умники из IAB крепко призадумались. И собрались снова - на этот раз в офлайне 4-го июня 2002-го года в Рестоне (это в Штатах - любопытный городок - почитайте), чтобы «продолжить важный диалог, начатый между операторами и протокол-девелоперами».

Сели, похаяли SNMP, покекали с аббревиатур COPS, SPPI, PIB, CIM, MOF и записали это всё в –тик-ток– RFC3535.

Выхлопом этой встречи стали 33 наблюдения и 8 рекомендаций. Среди них есть действительно важные, определившие наше настоящее.

1. Программные интерфейсы должны предоставлять полное покрытие,
иначе они не будут использоваться операторами, поскольку они
будут вынуждены использовать CLI.
5. Необходимо строгое разделение между конфигурационными и операционными
данными
8. Необходимо иметь возможность выгрузить и загрузить конфигурацию
в текстовом формате в единообразной манере между всеми вендорами
и типами устройства
9. Желательно иметь механизм доставки конфигурации в условиях
транзакционных ограничений.
14. Необходимо, чтобы устройства поддерживали как программный,
так и пользовательский интерфейс
15. Внутренние операции на устройстве должны быть одинаковы
как для программного, так и для пользовательского интерфейсов.
26. Должна быть возможность произвести операцию над указанной секцией
конфигурации.
27. Должна быть возможность выяснить возможности устройства
28. Необходимы безопасный транспорт, механизмы аутентификации
и авторизации, поддерживаемые текущей инфраструктурой.
30. Полная конфигурация устройства должна быть применима через один
протокол.

Часть из них мы воспринимаем сегодня как самоочевидное, мол, а как вы ещё иначе могли бы такое сделать? Но это не воспринималось так тогда. Просто вспомним как устроен SNMP :)

А ещё были явно полезные рекомендации:

• Рабочее совещание рекомендует прекратить форсить рабочие группы предоставлять конфигурационные MIB’ы
• Рабочее совещание рекомендует не тратить время на CIM, COPS-PR, SPPI PIB

В общем-то какие претензии к SNMP и его компании заставили уважаемых людей собраться на три дня?

• Проблемы масштабирования. Забирать большие объёмы данных с большого количества устройств он не был рассчитан.
• Транзакционность изменений на устройстве, и тем более на сети, должна была поддерживаться не протоколом и устройством, а системой инструментов.
• Откат также лежал на инструментах.
• Writable MIB не покрывали большей части задач по настройке устройства.
• Весь этот куст OID’ов был крайне сложночитаем для человека. Понять, что произойдёт после работы скрипта было очень сложно. Сколькие из вас отчаялись, пытаясь его понять?
• Не было никакого инструмента, который позволял бы повторно выполнить те же действия идемпотентно на этом же устройстве или на другом.
• Контроль состояния тоже отсутствовал.

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

Короткий итог встречи: IETF всё это время что-то там придумывал, разрабатывал, чтобы сделать жизнь операторов проще, а те не будь дураками, пришли и наконец сказали, что, мол, вы тут штаны просиживаете, а ничего полезного для нас не делаете, а делаете вы бесполезное! И ISO туда же!

И в этот момент Juniper из-за угла приоткрывает полу своего XML-API.

И он оказывается настолько более лаконичным (это XML-то!) и удобным, что рабочая группа внезапно решает принять его концепции в качестве стандарта NETwork CONFiguration protocol - RFC4741. Упор на Configuration в названии - это, видимо, гиперкомпенсация отсутствия режима конфигурации в SNMP.

Вот так в итоге скромно упомянут джунипер в этом RFC:

In the late 1990's, some vendors started to use the Extensible Markup
Language (XML) [XML] for describing device configurations and for
protocols that can be used to retrieve and manipulate XML formatted
configurations.

А через 5 лет, в 2011, исправленное и дополненное издание вышло под номером RFC6241. Там уже потрудились несколько университетов и компаний. Одной из них стала восходящая звезда сетевой автоматизации Tail-f, купленная и погубленная в 2014-м году циской. Нет, формально она, конечно, осталась внутри как отдельный Business Unit, но в большой мир они отсвечиваюь теперь только Cisco NSO, хотя могли бы приносить большую пользу. Впрочем, может, я зря наговариваю? Надо будет потрогать его.

И вот в операторские сети на белом коне въезжает NETCONF.

• Работает по SSH (и не только),
• Представляет данные в структурированном виде,
• Разделяет конфигурационные и операционные данные,
• Имеет несколько операций над данными: create, merge, replace, delete, remove,
• Может обеспечить контроль целевого состояния конфигурации,
• Поддерживает концепцию нескольких версий конфигурации (datastores),
• Может поддерживать commit конфигурации. Обеспечивает транзакционность,
• И вообще красавчик.

Причём Juniper его поддерживает с нулевого дня. И в полной мере, потому что для него это максимально естественно - это и есть его API.

А вот внутренний API той же Циски или Хуавэя не ложится так гладко на XML и какую-либо простую схему. Для них поддержка NETCONF - это большая работа, которую они выполняют с переменным успехом. Коммиты, операция replace - это всё даётся тяжело. А именно в них вся сила.

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

Commit обеспечивает три буквы ACID - Атомарность, Консистентность и Изолированность.

Операция Replace - мощнейшая штука - позволяет заменять всю или часть конфигурации на новую.

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

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

Для работы с NETCONF есть библиотеки для питона (и синхронные, и асинхронные), для го, плагины для Ансибл.

Вроде бы всё - бери и пользуйся. Но не все производители его поддерживают. И совсем немногие поддерживают его в полной мере. Где-то нельзя настроить DHCP-Relay, где-то нет секций IPv6-vpn AF в BGP, где-то replace не поддерживается или поддерживается, но работает через delete/create - ух, неспасибо за это.

В итоге пара пунктов из вышеупомянутого RFC3535 нарушены: не всё можно настроить через этот новый протокол, а для настройки всех возможных функций нужен как минимум CLI.

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