Лучшие вопросы
Таймлайн
Чат
Перспективы

NETCONF

Из Википедии, свободной энциклопедии

Remove ads

Сетевой протокол конфигурации, 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                 |
   |  протокол      |      |                                           |
   +----------------+      +-------------------------------------------+
Remove ads

Запросы

Суммиров вкратце
Перспектива

Базовые запросы

Базовая реализация протокола включает следующие виды запросов: <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.

Remove ads

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

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

Содержимое

Содержимое запросов 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 и распространено среди сообщества.

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

Remove ads

См. также

Ссылки

Remove ads
Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads