Конфигурации сетевого протокола ( NETCONF ) является управление сетью протокол , разработанный и стандартизованный IETF . Он был разработан рабочей группой NETCONF [1] и опубликован в декабре 2006 года как RFC 4741 [2], а затем пересмотрен в июне 2011 года и опубликован как RFC 6241. [3] Спецификация протокола NETCONF является документом Internet Standards Track.
NETCONF предоставляет механизмы для установки, управления и удаления конфигурации сетевых устройств. Его операции реализуются поверх простого уровня удаленного вызова процедур (RPC). Протокол NETCONF использует кодирование данных на основе расширяемого языка разметки (XML) для данных конфигурации, а также сообщений протокола. Обмен сообщениями протокола осуществляется поверх защищенного транспортного протокола.
Протокол NETCONF можно концептуально разделить на четыре уровня:
- Уровень содержимого состоит из данных конфигурации и данных уведомлений.
- Уровень операций определяет набор операций основного протокола для извлечения и редактирования данных конфигурации.
- Уровень сообщений предоставляет механизм для кодирования вызовов удаленных процедур (RPC) и уведомлений.
- Уровень Secure Transport обеспечивает безопасную и надежную передачу сообщений между клиентом и сервером.
Протокол NETCONF был реализован в сетевых устройствах, таких как маршрутизаторы и коммутаторы, некоторыми крупными поставщиками оборудования. Одной из сильных сторон NETCONF является поддержка надежного изменения конфигурации с использованием транзакций с участием ряда устройств.
История
IETF разработал простой протокол управления сетью (SNMP) в конце 1980-х годов, и он оказался очень популярным протоколом управления сетью . В начале 21 века стало очевидно, что, несмотря на то, что изначально предполагалось, SNMP не использовался для настройки сетевого оборудования, а в основном использовался для мониторинга сети . В июне 2002 года Совет по архитектуре Интернета и ключевые члены сообщества управления сетью IETF собрались вместе с операторами сетей, чтобы обсудить сложившуюся ситуацию. Результаты этой встречи задокументированы в RFC 3535. Оказалось, что каждый сетевой оператор в основном использовал свой собственный интерфейс командной строки (CLI) для настройки своих устройств. Он имел ряд функций, которые понравились операторам, в том числе тот факт, что он был основан на тексте, в отличие от SNMP с кодировкой BER . Кроме того, многие поставщики оборудования не предоставляют возможность полностью настроить свои устройства через 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 Object Notation (JSON).
Рабочая группа NETMOD завершила работу по определению «удобного для человека» языка моделирования для определения семантики рабочих данных, данных конфигурации, уведомлений и операций, называемого YANG . YANG определен в RFC 6020 (версия 1) и RFC 7950 (версия 1.1) и сопровождается «Общими типами данных YANG», найденными в RFC 6991.
Летом 2010 года рабочая группа NETMOD была переименована для работы над основными моделями конфигурации (система, интерфейс и маршрутизация), а также над совместимостью с языком моделирования SNMP .
Операции
Базовый протокол определяет следующие операции протокола:
Операция | Описание |
---|---|
<получить> | Получение информации о текущей конфигурации и состоянии устройства |
Получить все или часть указанного хранилища данных конфигурации | |
Редактировать хранилище данных конфигурации, создавая, удаляя, объединяя или заменяя контент | |
Скопируйте все хранилище данных конфигурации в другое хранилище данных конфигурации | |
Удалить хранилище данных конфигурации | |
<блокировка> | Заблокировать все хранилище данных конфигурации устройства |
<разблокировать> | Снимите блокировку хранилища данных конфигурации, полученную ранее с помощью операции |
<закрытая сессия> | Запросить постепенное завершение сеанса NETCONF |
<убийство-сессия> | Принудительное завершение сеанса NETCONF |
Базовая функциональность NETCONF может быть расширена определением возможностей NETCONF. Набор дополнительных функций протокола, поддерживаемых реализацией, передается между сервером и клиентом во время части обмена возможностями настройки сеанса. Обязательные функции протокола не включаются в обмен возможностями, поскольку они предполагаются. RFC 4741 определяет ряд дополнительных возможностей, включая xpath и: validate. Обратите внимание, что RFC 6241 отменяет RFC 4741.
Возможность поддержки подписки и получения асинхронных уведомлений о событиях опубликована в RFC 5277. Этот документ определяет операцию
Возможность поддержки частичной блокировки текущей конфигурации определена в 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 поверх Transport Layer Security (TLS) с взаимной аутентификацией X.509: rfc: 7589
Смотрите также
- ЯН
- Стефан Валлин (18.10.2014). Учебное пособие по NETCONF (YouTube). Стокгольм: хвост-ф.
- Управление сетью
- Управление конфигурацией
- Сетевой мониторинг
- Схема XML
Рекомендации
- ^ «Рабочая группа по настройке сети» . IETF.
- ^ Эннс, Роб (2006). Протокол конфигурации NETCONF (Технический отчет). IETF. DOI : 10,17487 / RFC4741 . RFC4741.
- ^ Эннс, Роб; Бьёрклунд, Мартин; Шенвельдер, Юрген; Бирман, Энди (2011). Протокол конфигурации сети (NETCONF) (Технический отчет). IETF. DOI : 10,17487 / RFC6241 . RFC6241.