NETCONF
Сетевой протокол конфигурации, NETCONF, является протоколом сетевого управления устройствами. Он был разработан в рамках рабочей группы NETCONF и впервые опубликован в RFC 4741, который был переработан в RFC 6241 в июне 2011.
NETCONF предоставляет механизмы установки, управления и удаления конфигурации сетевых устройств посредством удаленного вызова процедур RPC. NETCONF использует XML как средство предоставления конфигурации и как средство формирования сообщений протокола, который реализуется поверх транспортного.
NETCONF может быть схематично разделен на четыре уровня:
Уровень Пример +----------------+ +-------------------------------------------+ | Содержимое | | Конфигурация устройства | +----------------+ +-------------------------------------------+ | | +----------------+ +-------------------------------------------+ | Операции | |<get-config>, <edit-config>, <notification>| +----------------+ +-------------------------------------------+ | | | +----------------+ +-----------------------------+ | | RPC | | <rpc>, <rpc-reply> | | +----------------+ +-----------------------------+ | | | | +----------------+ +-------------------------------------------+ | Транспортный | | BEEP, SSH, SSL, console | | протокол | | | +----------------+ +-------------------------------------------+
Запросы
[править | править код]Базовые запросы
[править | править код]Базовая реализация протокола включает следующие виды запросов: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <close-session>, <kill-session>.
Возможности протокола
[править | править код]Базовая функциональность NETCONF может быть расширена посредством дополнений. При установке сессии клиент и сервер обмениваются друг с другом информацией об установленных расширениях. RFC 4741 определяет дополнительные возможности, в частности: xpath и: validate.
Возможность подписки и получения асинхронных сообщений опубликована в RFC 5277. Она определяет запрос типа <create-subscription>, который включает возможность подписки на сообщения реального времени. В свою очередь сообщения отправляются посредством инструкции <notification>. RFC также определяет возможность: interleave, которая совместно с: notification помогает обрабатывать различные NETCONF запросы во время включенной подписки.
Дополнительные возможности включают блокировку части конфигурации. Это позволяет в рамках нескольких сессий редактировать не перекрывающиеся деревья в исполняемой конфигурации. Без этого дополнения возможна только блокировка всей конфигурации.
В данный момент рабочая группа работает над поддержкой сообщений, позволяющих обмениваться шаблонами (XML Schema, Relax NG, etc.), которые определяют дерево NETCONF.
Транспортный протокол
[править | править код]NETCONF может работать поверх нескольких транспортных протоколов:
- SSH (RFC 4742), который является обязательным в реализации NETCONF
- SOAP (RFC 4743)
- BEEP (RFC 4744)
- TLS (RFC 5539)
Содержимое
[править | править код]Содержимое запросов NETCONF представляет собой валидный XML, большая часть которого относится к конфигурации устройства.
Рабочая группа NETMOD закончила работу по созданию человеко-ориентированного языка для представления текущего состояния устройства, конфигурации, оповещений и операций, называемый YANG. YANG определен в RFC 6020 и дополнен RFC 6021, в котором представленные основные типы данных.
В течение лета 2010 рабочей группе NETMOD была предоставлена возможность поработать над моделью конфигурации (системы, интерфейсов, маршрутизации), совместимой с моделью SNMP.
История
[править | править код]В конце 80-х IETF разработал SNMP, который стал очень популярным. Несмотря на то, что SNMP предоставлял возможность конфигурирования устройств, этим протоколом пользовались по большому счету для мониторинга сетей. В 2002 году Совет по архитектуре Интернета и ключевые члены IETF-сообщества объединились с операторами связи, чтобы обсудить эту ситуацию. Результаты обсуждения опубликованы в RFC 3535. На тот момент операторы связи использовали проприетарный командный интерфейс для конфигурирования своих устройств. Интерфейс имел множество удобств, в отличие от SNMP. К тому же, множество производителей не позволяли полностью конфигурировать свои устройства через SNMP. Сетевые инженеры в основном писали скрипты, которые помогали им управлять устройствами, однако, командный интерфейс в этом случае является причиной многих сложностей. Наиболее значимой из которых является непредсказуемось вывода, формируемого сетевым устройством. Содержимое и форматирование вывода имеет склонность к изменениям в не всегда предсказуемую сторону.
В то же время компания Juniper Networks использовала основанную на XML конфигурацию. Это было предложено в IETF и распространено среди сообщества.
Эти два факта послужили причиной создания протокола, который удовлетворял бы требованиям как сетевых операторов так и поставщиков оборудования.
См. также
[править | править код]Ссылки
[править | править код]- Network Configuration (netconf) Working Group Charter
- NETCONF Data Modeling Language (netmod) Working Group Charter
- NETCONF WG Wiki Page
- Yuma: Open Source NETCONF implementation and YANG compiler
- pyang: Open Source YANG compiler
- Netconf Central: NETCONF information and tutorials
- Yang Central: YANG tutorials, and freely available YANG and DSDL tools
- RFC 5381: Experience of Implementing NETCONF over SOAP