NETCONF/YANG предоставляет стандартизированный способ программного обновления и изменения конфигурации сетевого устройства. Продолжим, чтобы разрушить это утверждение. YANG — это язык моделирования, который описывает изменения конфигурации. В то время как NETCONF — это протокол, который применяет изменения в соответствующей памяти (текущая и стартовая конфигурация) на устройстве.
Начнем с проблемы. Исторически сложилось так, что основным методом настройки сетевого устройства был интерфейс командной строки или, в некоторых случаях, SNMP. Однако эти методы вызвали ряд проблем.
Недостатки CLI:
- Вводные команды отличается от поставщика к поставщику.
- Вывод команд отличается у каждого поставщика. Требуется отдельная логика синтаксического анализа для каждого поставщика.
- Структура и синтаксис CLI подвержены изменениям. Это делает наши скрипты CLI ненадежными.
Недостатки SNMP:
- Ненадежный, поскольку изначально использует UDP в качестве транспортного протокола.
- Традиционно небезопасный. Хотя протокол SNMPv3 пытается решить эту проблему, он по-прежнему имеет свои проблемы с безопасностью. В основном это сообщения обнаружения, используемые для согласования ключей аутентификации и шифрования, которые не запаролены и не зашифрованы.
- Нет четкого разграничения между данными конфигурации и данными мониторинга. В результате на стороне клиента должны выполняться дополнительные процессы для сортировки.
- Отсутствуют стандартные MIB для настройки сетей. Вот почему производители разработали различные патентованные MIB, которые стали препятствием для управления платформами разных производителей.
- Не предоставляет реальной модели транзакционных операций, позволяющей выполнять простые откаты и т. д. С распространением сетевой автоматизации (что-то вроде SDN или Northbound Interface) возникла потребность в стандартизации и улучшении способа программирования сетевых устройств. Способ, который бы обеспечил:
- Программный интерфейс для настройки устройства.
- Разделение данных конфигурации и состояния.
- Возможность настраивать сервисы, а не только устройства.
- Встроенная проверка ошибок и восстановление.
Решение этой проблемы пришло от IETF в форме NETCONF и YANG. В своей простейшей форме YANG предоставляет язык для описания вашей желаемой конфигурации (или состояния). NETCONF, с другой стороны, предоставляет протокол для доставки и выполнения необходимых операций для достижения желаемого состояния, описанного в модели YANG.
YANG
YANG (Yet Another Next Generation) — это язык моделирования данных, обеспечивающий стандартизированный способ моделирования рабочих и конфигурационных данных сетевого устройства. YANG, будучи языком не зависит от протокола, может быть преобразован в любой формат кодирования, например XML или JSON.
ОТКРЫТЫЕ/СОБСТВЕННЫЕ МОДЕЛИ
Вы можете спросить, кто создает эти модели? Модели классифицируются на открытые и собственные, с каждой из которых работают разные группы.
Открытые модели — разработаны, чтобы быть независимыми от базовой платформы и нормализовать конфигурацию сетевых устройств для каждого поставщика. Модели Open YANG разрабатываются поставщиками и органами по стандартизации, такими как IETF, ITU, OpenConfig и т. д.
Собственные (Native) модели разрабатываются поставщиками. Они связаны и предназначены для интеграции с функциями или конфигурацией, относящимися только к этой платформе.
КОМПОНЕНТЫ
Модель YANG состоит из различных компонентов. Давайте разберем каждый из них:
- Контейнер — набор логически сгруппированной информации. Один такой контейнер для конфигурации, и один для состояния.
- Список — внутри контейнера вы можете иметь список или даже несколько списков. Например, список интерфейсов. Ключ. Каждый элемент в списке ссылается на ключ. Лист — внутри каждого списка у нас есть лист, который содержит информацию.
- Тип данных — каждый лист связан с типом данных.
NETCONF
NETCONF (NETwork CONFiguration) — это протокол, определенный IETF для «установки, управления и удаления конфигурации сетевых устройств». Операции NETCONF выполняются через уровень RPC с использованием кодирования на основе XML.
Некоторые из ключевых особенностей NETCONF: возможность отката конфигураций, возможность поддержки любой модели данных и отделение конфигурации от рабочего состояния.
СТЕК ПРОТОКОЛОВ
Протокол NETCONF можно разбить на 4 уровня. Такие как:
- Контент — модели данных NETCONF и операции протокола используют язык моделирования YANG (RFC 6020). Модель данных описывает структуру, семантику и синтаксис данных.
- Операции — набор операций базового протокола, инициируемых методами RPC с использованием XML-кодирования, для выполнения операций на устройстве. Такие как <get-config>, <edit-config> и <get>.
- Сообщения — для использования определен набор сообщений и уведомлений RPC, включая <rpc>, <rpc-reply> и <rpc-error>.
- Транспорт — транспортный уровень, используемый для обеспечения пути связи между клиентом/сервером (менеджером/агентом). Используемый протокол не зависит от NETCONF, но обычно используется SSH.
ОБМЕН ИНФОРМАЦИЕЙ
NETCONF основан на модели клиент/сервер, известной как — менеджер и агент. В коммуникационном потоке сеанса NETCONF есть 3 основные части:
Установление сеанса — каждая сторона отправляет вместе со своими <capabilities>. Объявляя, какие операции (возможности) он поддерживает.
Запрос операции — затем клиент отправляет свой запрос (операцию) серверу через сообщение <rpc>. Затем ответ отправляется обратно клиенту в <rpc-reply>.
Закрытие сеанса — затем сеанс закрывается клиентом через <close-session>.
ОПЕРАЦИИ
Действия выполняются над сетевым устройством (и его хранилищами данных) с помощью набора операций. Каждая из операций связана с возможностями устройств (клиента или сервера). Например, если мы посмотрим на <get-config>, он поддерживается функцией :base.
| Наименование операции |
Описание |
| <get> | Получить текущую конфигурацию и информацию о состоянии |
| <get-config> | Получить все или часть указанного хранилища данных конфигурации |
| <edit-config> | Загрузить всю или часть конфигурации в указанное хранилище данных конфигурации |
| <copy-config> | Заменить все хранилище данных конфигурации другим хранилищем данных |
| <delete-config> | Удалить хранилище данных конфигурации |
| <discard-changes> | Удалить все изменения из и приведите его в соответствие с хранилищем данных конфигурации |
| <create-subscription> | Создать подписку на уведомления NETCONF |
| <commit> | Скопировать хранилище данных кандидата в текущее хранилище данных |
| <cancel-commit> | Отменить текущую подтвержденную фиксацию |
| <lock> | Заблокировать всю систему хранилища данных конфигурации, который может записать сеанс |
| <unlock> | Разблокировать всю систему хранения данных конфигурации, которая может записать сеанс |
| <closed session> | Грамотное завершение сеанса NETCONF |
| <kill-session> | Принудительное завершение сеанса NETCONF |
ХРАНИЛИЩА ДАННЫХ КОНФИГУРАЦИИ
Существует 4 хранилища данных конфигурации NETCONF — Running, Startup, Candidate и URL. Затем с этими хранилищами данных выполняются действия с помощью различных операций NETCONF (как упоминалось ранее):
- Running — хранилище данных конфигурации, содержащее конфигурацию, которая применена и выполняется на сетевом устройстве.
- Startup — хранилище данных конфигурации, в котором хранится конфигурация, загружаемая устройством при включении.
- Candidate — хранилище данных конфигурации, которым можно управлять, не влияя на текущую конфигурацию устройства, и которое может быть передано в текущее хранилище данных конфигурации.
- URL-адрес — хранилище данных конфигурации, конфигурация которого находится в отдельном месте, доступ к которому осуществляется через URL-адрес.