NETCONF. Начало

Некоторые слышали, а некоторые даже уверены, что есть "простой протокол управления сетями", больше известный как SNMP (Simple Network Management Protocol).
Но мне почти не встречались люди, знающие про NETCONF, который, как надеются его создатели, станет заменой SNMP.

Что же он из себя представляет? Это аналог SNMP? Это эволюция управления? Или это тупиковая ветвь?

Коротко о NETCONF

Итак, NETCONF — это Network Configuration Protocol (ага, слова «simple» (простой) нет, видимо, в этом его проблема). Разрабатывается он IETF NETCONF Working Group ^[1]. Его «жизнь» началась в декабре 2006 с RFC 4741 ^[2], а в июне 2011 выкатили RFC 6241 ^[3].
Появился он из недр компании Juniper, а еще точнее является допиленным напильником Junos XML API.

Чем плох SNMP?

И правда, зачем изобретать NETCONF? Ведь SNMP еще вполне «свежий» протокол, появившийся в конце 80х (SNMPv1 в 1988). Для сравнения: telnet разрабатывался в 1969 году, а им до сих пор пользуются. Даже придумали SNMPv3 с шифрованием.

И все же, в 2002 была встреча Internet Architecture Board (IAB) Network Management Workshop, результатом которой стал RFC 3535 ^[4]. В частности в нем перечислены плюсы и минусы технологий управления сетями (пункт 2) и в т.ч. SNMP (пункт 2.1).

Перечислю несколько самых явных на мой взгляд минусов SNMP:

• В большинстве реализаций в качестве транспортного протокола применяется UDP. Если что-то где по пути потерялось, ну, что поделать.
• Можно записывать/считывать только одно определенное значение за один раз. Нельзя послать несколько значений в одной транзакции.
• Нет возможности откатов/бэкапов конфигурации: snmp set делает изменение сразу в активной конфигурации.
• Ограничения в SMI (например, длины некоторых полей).
• Зоопарк MIB даже у одного вендора, даже в одном типе устройств, например, коммутаторов.
• Бывают задержки с поддержкой новых фич в старых MIB. Например, CISCO-BGP-MIB, насколько мне известно, до сих пор не знает про IPv6.

Препарируем NETCONF

По-моему, протокол очень простой, а RFC очень хорошо написан.

Концептуально NETCONF выглядит так:

Картинку взял тут ^[5].

В качестве транспорта в данный момент определено 4 варианта:

• SSH
• SOAP
• BEEP
• TLS

Операции «оборачиваются» в RPC запросы, представленные в XML.

Определены следующие базовые операции:

<get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <close-session>, <kill-session>.

Применяется клиент-серверная модель работы протокола. Установленную сессию можно держать сколько угодно долго (пока будет связность и пока «жив» «сервер»).

При установке соединения клиент и сервер обмениваются поддерживаемыми параметрами (с помощью RPC уведомлений).

Что же мы можем? А мы можем, например:

• открывать несколько сессий
• работать с разными конфигурациями (например: running или startup)
• запрашивать конфигурацию и состояние одним запросом с поиском
• производить конфигурацию нескольких параметров одним запросом
• получать результаты операций в виде ответов (rpc-reply)
• делать commit и rollback (применение и откат конфигураций)

Думаю, проще всего понять работу с NETCONF на примере.

Пример работы NETCONF на Juniper

Включаем NETCONF:

set system services netconf ssh

И попробуем подключиться:

ssh username@host -s netconf

После ввода пароля (или проверки ключа) получаем hello от «сервера»:

<!-- No zombies were killed during the creation of this user interface -->
<!-- user test, class j-super-user -->
<hello>
 <capabilities>
  <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability>
  <capability>xml.juniper.net/netconf/junos/1.0 [6]</capability>
  <capability>xml.juniper.net/dmi/system/1.0 [7]</capability>
 </capabilities>
 <session-id>666</session-id>
</hello>
]]>]]>

* This source code was highlighted with Source Code Highlighter [8].

Сервер сообщил нам списком своих capability (возможностей).
Про зомби — это шутка, встречается в Junos такое иногда. Например, есть еще скрытая команда, показывающая хайку ^[9]:

show version and haiku

В ответ на hello клиент должен ответить своим hello со списком своих capability, например, такими же:

<hello>
 <capabilities>
  <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability>
  <capability>xml.juniper.net/netconf/junos/1.0 [6]</capability>
  <capability>xml.juniper.net/dmi/system/1.0 [7]</capability>
 </capabilities>
</hello>
]]>]]>

* This source code was highlighted with Source Code Highlighter [8].

Всё. Теперь можно работать с сервером. Например, спросить часть текущей конфигурации:

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
   <source>
     <running/>
   </source>
   <filter type="subtree">
  <configuration>
    <protocols/>
  </configuration>
   </filter>
  </get-config>
</rpc>

* This source code was highlighted with Source Code Highlighter [8].

На что получим ответ:

<rpc-reply message-id="100" xmlns:junos="http://xml.juniper.net/junos/11.2R5/junos">
  <configuration junos:commit-seconds="1311003260" junos:commit-localtime="2012-06-06 11:21:40 UTC" junos:commit-user="test">
      <protocols>
SKIPPED
      </protocols>
  </configuration>
</rpc-reply>

* This source code was highlighted with Source Code Highlighter [8].

message-id=«100», указанный в запросе, сохраняется и в ответе. Т.о. можно различать разные ответы, которые могут быть получены в разном порядке.

Кроме rpc-reply можно словить rpc-error, когда произошла ошибка при обработке запроса от клиента. Пример из RFC:

   <rpc-reply message-id="110" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
     <error-type>rpc</error-type>
     <error-tag>missing-attribute</error-tag>
     <error-severity>error</error-severity>
     <error-info>
      <bad-attribute>message-id</bad-attribute>
      <bad-element>rpc</bad-element>
     </error-info>
    </rpc-error>
   </rpc-reply>

* This source code was highlighted with Source Code Highlighter [8].

В случае же удачно выполненного запроса, не требующего вывода (например, команды), сервер отвечает OK, например:

   <rpc-reply message-id="201" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
   </rpc-reply>

* This source code was highlighted with Source Code Highlighter [8].

Чтобы закончить работу, мы должны закрыть сессию:

<rpc message-id="100500" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <close-session/>
</rpc>

* This source code was highlighted with Source Code Highlighter [8].

Где работает NETCONF?

Ходят слухи, что на устройствах Juniper, Brocade, Cisco, Huawei и некоторых других.

… НО

Не так всё прекрасно. Отлично документированный и поддерживаемый NETCONF я встречал только на Juniper. К сожалению, на Huawei его не испытывал, т.к. не было необходимости, а в случае с Brocade не было подопытных. Но Cisco…

О работе NETCONF на линейке Catalyst как минимум до 15 версии IOS:

• Ответы на запросы очень сильно пожирают CPU. running-config c XML форматированием можно ждать минут 5 при загрузке CPU под 100%.
• get состояния реализован не по RFC (sic!): в ответ к, например, «show int status» Cisco всегда добавляет полный running-config.
• Нет XML схем и выдача иногда странным образом обрезается. Например, на запрос «sh run int vlan777» Cisco отвечает так:
  

  <?xml version="1.0" encoding="UTF-8"?><rpc-reply message-id="101" xmlns="urn:ietf:params:netconf:base:1.0&#60;/cmd>a><cli-config-data><cmd>!
</cmd>nterface Vlan777
</cmd>description TEST
</cmd>ip address 192.168.0.1 255.255.255.0
</cmd></cli-config-data></data></rpc-reply>]]>]]>

  * This source code was highlighted with Source Code Highlighter [8].

  Куда-то пропала первая буква в слове «Interface».

По-моему, реализация Cisco скорее для галочки, нежели для работы.

Заключение

Я хотел вкратце рассказать про NETCONF, т.к. на Хабре не нашел о нем даже упоминания.
Думаю, протокол вполне способен жить и приносить пользу.
Так же хотелось бы услышать другие мнения в комментариях, особенно интересна работоспособность с разным оборудованием.

Автор: