NETCONF - NETCONF

Уровни протокола NETCONF.

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

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

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

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

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

История

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

Примерно в это же время 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 завершила работу по определению «удобного для человека» языка моделирования для определения семантики рабочих данных, данных конфигурации, уведомлений и операций, называемого ЯН. Ян определяется в RFC 6020 (версия 1) и RFC 7950 (версия 1.1) и сопровождается "Общими типами данных YANG", которые можно найти в RFC 6991.

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

Операции

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

ОперацияОписание
<get>Получение информации о текущей конфигурации и состоянии устройства
<get-config>Получить все или часть указанного хранилища данных конфигурации
<edit-config>Редактировать хранилище данных конфигурации, создавая, удаляя, объединяя или заменяя содержимое
<copy-config>Скопируйте все хранилище данных конфигурации в другое хранилище данных конфигурации
<delete-config>Удалить хранилище данных конфигурации
<lock>Заблокировать все хранилище данных конфигурации устройства
<unlock>Снимите блокировку хранилища данных конфигурации, полученную ранее с помощью операции
<close-session>Запросить корректное завершение сеанса NETCONF
<kill-session>Принудительное завершение сеанса NETCONF

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

Возможность поддержки подписки и получения асинхронных уведомлений о событиях опубликована в RFC 5277. В этом документе определяется операция , которая позволяет создавать подписки в реальном времени и воспроизводить подписки. Затем уведомления отправляются асинхронно с использованием конструкции . Он также определяет возможность: interleave, которая, если поддерживается с возможностью basic: notification, облегчает обработку других операций NETCONF во время действия подписки.

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

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

Сообщения

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

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

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

Транспорт

  • Протокол NETCONF через защищенную оболочку (SSH): RFC: 6242
  • Протокол NETCONF через безопасность транспортного уровня (TLS) с взаимной аутентификацией X.509: rfc: 7589

Смотрите также

  • ЯН
  • Стефан Валлин (18.10.2014). NETCONF Учебное пособие (YouTube). Стокгольм: хвост-ф.
  • Управление сетью
  • Управление конфигурацией
  • Сетевой мониторинг
  • Схема XML

Рекомендации

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