NETCONF

Протокол конфигурации сети ( NETCONF ) — это протокол управления сетью, разработанный и стандартизированный IETF . Он был разработан в рабочей группе NETCONF. ^[1] и опубликован в декабре 2006 г. как RFC 4741. ^[2] а затем пересмотрен в июне 2011 года и опубликован как RFC 6241. ^[3] Спецификация протокола NETCONF представляет собой документ стандарта Интернета.

NETCONF предоставляет механизмы для установки, управления и удаления конфигурации сетевых устройств. Его операции реализуются поверх простого уровня удаленного вызова процедур (RPC). Протокол NETCONF использует кодирование данных на основе расширяемого языка разметки (XML) для данных конфигурации, а также сообщений протокола. Сообщения протокола обмениваются поверх безопасного транспортного протокола.

Протокол NETCONF концептуально можно разделить на четыре уровня:

Уровень контента состоит из данных конфигурации и данных уведомлений.
Уровень операций определяет набор операций базового протокола для получения и редактирования данных конфигурации.
Уровень сообщений предоставляет механизм кодирования удаленных вызовов процедур (RPC) и уведомлений.
Уровень безопасного транспорта обеспечивает безопасную и надежную транспортировку сообщений между клиентом и сервером.

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

История [ править ]

IETF разработал простой протокол управления сетью (SNMP) в конце 1980-х годов, и он оказался очень популярным управления сетью протоколом . В начале 21 века стало очевидно, что, несмотря на то, что изначально предполагалось, SNMP не использовался для настройки сетевого оборудования, а в основном использовался для мониторинга сети . В июне 2002 года Совет по архитектуре Интернета и ключевые члены сообщества управления сетями IETF собрались вместе с сетевыми операторами, чтобы обсудить ситуацию. Результаты этой встречи задокументированы в RFC 3535. Оказалось, что каждый сетевой оператор в основном использовал свой собственный интерфейс командной строки (CLI) для настройки своих устройств. Он имел ряд особенностей, которые нравились операторам, в том числе тот факт, что он был текстовым, а не SNMP с кодировкой BER . Кроме того, многие производители оборудования не предоставили возможность полной настройки своих устройств через SNMP. Поскольку операторы обычно любили писать сценарии для управления своими устройствами, они обнаружили, что SNMP CLI не хватает по ряду причин. В частности, был непредсказуемый характер результатов. Содержание и форматирование вывода могли меняться непредсказуемым образом.

Примерно в то же время компания Juniper Networks использовала подход к управлению сетью на основе XML. Это было передано в IETF и распространено среди более широкого сообщества. В совокупности эти два события привели IETF в мае 2003 года к созданию рабочей группы NETCONF. Эта рабочая группа была создана для работы над протоколом конфигурации сети, который лучше соответствовал бы потребностям сетевых операторов и поставщиков оборудования. Первая версия базового протокола NETCONF была опубликована как RFC 4741 в декабре 2006 года. В последующие годы было опубликовано несколько расширений (уведомления в RFC 5277 в июле 2008 года, частичные блокировки в RFC 5717 в декабре 2009 года, со значениями по умолчанию в RFC 6243 в июне). 2011 г., системные уведомления в RFC 6470 в феврале 2012 г., контроль доступа в RFC 6536 в марте 2012 г.). Пересмотренная версия базового протокола NETCONF была опубликована как RFC 6241 в июне 2011 года.

Уровни протокола [ править ]

Содержание [ править ]

Содержимое операций NETCONF представляет собой правильно сформированный XML. Большая часть контента связана с управлением сетью . Впоследствии также была добавлена поддержка кодирования в нотации объектов JavaScript (JSON).

Рабочая группа NETMOD завершила работу по определению «дружественного к человеку» языка моделирования для определения семантики операционных данных, данных конфигурации, уведомлений и операций, получившего название YANG . YANG определен в RFC 6020 (версия 1) и RFC 7950 (версия 1.1) и сопровождается «Общими типами данных YANG», найденными в RFC 6991.

Летом 2010 года рабочая группа NETMOD была переформирована для работы над основными моделями конфигурации (система, интерфейс и маршрутизация), а также для работы над совместимостью с языком моделирования SNMP .

Операции [ править ]

Базовый протокол определяет следующие операции протокола:

Операция	Описание
<получить>	Получение текущей конфигурации и информации о состоянии устройства.
<получить-конфигурацию>	Получить все или часть указанного хранилища данных конфигурации.
<редактировать-конфигурацию>	Редактируйте хранилище данных конфигурации, создавая, удаляя, объединяя или заменяя содержимое.
<копия-конфигурация>	Скопируйте все хранилище данных конфигурации в другое хранилище данных конфигурации.
<удалить-конфигурацию>	Удаление хранилища данных конфигурации
<блокировка>	Блокировка всего хранилища данных конфигурации устройства
<разблокировать>	Снимите блокировку хранилища данных конфигурации, полученную ранее с помощью операции <lock>.
<закрытие сессии>	Запросить корректное завершение сеанса NETCONF
<сессия-убийства>	Принудительное завершение сеанса NETCONF

Базовая функциональность NETCONF может быть расширена путем определения возможностей NETCONF. Набор дополнительных функций протокола, поддерживаемых реализацией, передается между сервером и клиентом во время части обмена возможностями установки сеанса. Обязательные функции протокола не включены в обмен возможностями, поскольку они предполагаются. RFC 4741 определяет ряд дополнительных возможностей, включая :xpath и :validate. Обратите внимание, что RFC 6241 устарел RFC 4741.

Возможность поддержки подписки и получения асинхронных уведомлений о событиях опубликована в RFC 5277. Этот документ определяет операцию <create-subscription>, которая позволяет создавать подписки в режиме реального времени и подписки с воспроизведением. Уведомления затем отправляются асинхронно с использованием конструкции <notification>. Он также определяет возможность :interleave, которая при поддержке базовой возможности :notification облегчает обработку других операций NETCONF, пока подписка активна.

Возможность поддержки частичной блокировки работающей конфигурации определена в RFC 5717. Это позволяетнесколько сеансов для редактирования непересекающихся поддеревьев в текущей конфигурации. Без этой возможности блокировка доступна только для всей конфигурации.

Возможность мониторинга протокола NETCONF определена в RFC 6022. Этот документ содержит модель данных, включая информацию о хранилищах данных NETCONF, сеансах, блокировках и статистике, которая облегчает управление сервером NETCONF. Он также определяет методы, позволяющие клиентам NETCONF обнаруживать модели данных, поддерживаемые сервером NETCONF, и определяет операцию <get-schema> для их получения.

Сообщения [ править ]

Уровень сообщений NETCONF обеспечивает простой, независимый от транспорта механизм формирования кадров для кодирования.

Вызовы RPC (сообщения <rpc>),
Результаты RPC (сообщения <rpc-reply>) и
уведомления о событиях (сообщения <notification>).

Каждое сообщение NETCONF представляет собой правильно сформированный XML-документ. Результат RPC связан с вызовом RPC атрибутом message-id. Сообщения NETCONF могут передаваться по конвейеру, т. е. клиент может вызывать несколько RPC без необходимости предварительного ожидания сообщений о результатах RPC. Сообщения RPC определены в RFC 6241, а сообщения уведомлений — в RFC 5277.

Транспорт [ править ]

Протокол NETCONF через Secure Shell (SSH): rfc:6242.
Протокол NETCONF через Transport Layer Security (TLS) с взаимной аутентификацией X.509: rfc:7589

См. также [ править ]

КОТОРЫЙ
Стефан Валлин (18 октября 2014 г.). Учебное пособие по NETCONF (YouTube). Стокгольм: хвост-f. Архивировано из оригинала 21 декабря 2021 г.
Управление сетью
Управление конфигурацией
Мониторинг сети
XML-схема

Ссылки [ править ]

^ «Рабочая группа по настройке сети» . IETF.
^ Эннс, Роб (2006). Протокол конфигурации NETCONF (Технический отчет). IETF. дои : 10.17487/RFC4741 . RFC4741.
^ Эннс, Роб; Бьорклунд, Мартин; Шенвальдер, Юрген; Бирман, Энди (2011). Протокол сетевой конфигурации (NETCONF) (Технический отчет). IETF. дои : 10.17487/RFC6241 . RFC6241.

[1] «Рабочая группа по настройке сети» . IETF.

[2] Эннс, Роб (2006). Протокол конфигурации NETCONF (Технический отчет). IETF. дои : 10.17487/RFC4741 . RFC4741.

[3] Эннс, Роб; Бьорклунд, Мартин; Шенвальдер, Юрген; Бирман, Энди (2011). Протокол сетевой конфигурации (NETCONF) (Технический отчет). IETF. дои : 10.17487/RFC6241 . RFC6241.

[1]

[2]

[3]