Interested Article - NETCONF

Сетевой протокол конфигурации, NETCONF , является протоколом сетевого управления устройствами. Он был разработан в рамках рабочей группы NETCONF и впервые опубликован в , который был переработан в в июне 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 может быть расширена посредством дополнений. При установке сессии клиент и сервер обмениваются друг с другом информацией об установленных расширениях. определяет дополнительные возможности, в частности: xpath и: validate.

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

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

В данный момент рабочая группа работает над поддержкой сообщений, позволяющих обмениваться шаблонами ( XML Schema , , etc.), которые определяют дерево NETCONF.

Транспортный протокол

NETCONF может работать поверх нескольких транспортных протоколов:

SSH ( ), который является обязательным в реализации NETCONF
SOAP ( )
( )
TLS ( )

Содержимое

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

Рабочая группа NETMOD закончила работу по созданию человеко-ориентированного языка для представления текущего состояния устройства, конфигурации, оповещений и операций, называемый . определен в и дополнен , в котором представленные основные типы данных.

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

История

В конце 80-х IETF разработал SNMP , который стал очень популярным. Несмотря на то, что SNMP предоставлял возможность конфигурирования устройств, этим протоколом пользовались по большому счету для мониторинга сетей. В 2002 году Совет по архитектуре Интернета и ключевые члены IETF-сообщества объединились с операторами связи, чтобы обсудить эту ситуацию. Результаты обсуждения опубликованы в . На тот момент операторы связи использовали проприетарный командный интерфейс для конфигурирования своих устройств. Интерфейс имел множество удобств, в отличие от SNMP. К тому же, множество производителей не позволяли полностью конфигурировать свои устройства через SNMP. Сетевые инженеры в основном писали скрипты, которые помогали им управлять устройствами, однако, командный интерфейс в этом случае является причиной многих сложностей. Наиболее значимой из которых является непредсказуемось вывода, формируемого сетевым устройством. Содержимое и форматирование вывода имеет склонность к изменениям в не всегда предсказуемую сторону.

В то же время компания Juniper Networks использовала основанную на XML конфигурацию. Это было предложено в IETF и распространено среди сообщества.

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