NETCONF. Начало

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

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


    Коротко о NETCONF


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

    Чем плох SNMP?


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

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

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


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



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

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

    Картинку взял тут.

    В качестве транспорта в данный момент определено 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</capability>
      <capability>xml.juniper.net/dmi/system/1.0</capability>
     </capabilities>
     <session-id>666</session-id>
    </hello>
    ]]>]]>


    * This source code was highlighted with Source Code Highlighter.


    Сервер сообщил нам списком своих capability (возможностей).
    Про зомби — это шутка, встречается в Junos такое иногда. Например, есть еще скрытая команда, показывающая хайку:
    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</capability>
      <capability>xml.juniper.net/dmi/system/1.0</capability>
     </capabilities>
    </hello>
    ]]>]]>


    * This source code was highlighted with Source Code Highlighter.


    Всё. Теперь можно работать с сервером. Например, спросить часть текущей конфигурации:
    <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.


    На что получим ответ:
    <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.


    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.


    В случае же удачно выполненного запроса, не требующего вывода (например, команды), сервер отвечает 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.


    Чтобы закончить работу, мы должны закрыть сессию:
    <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.


    Где работает 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.

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

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

    Заключение


    Я хотел вкратце рассказать про NETCONF, т.к. на Хабре не нашел о нем даже упоминания.
    Думаю, протокол вполне способен жить и приносить пользу.
    Так же хотелось бы услышать другие мнения в комментариях, особенно интересна работоспособность с разным оборудованием.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 20

      +4
      Не понятно как слать этот самый xml-запрос?..

      p.s. Единственное что могу сказать — xml меня убивает! ИМХО, это излишние мучения и геморрой писать запрос, где в такой архитектуре нету необходимости.
        +2
        SSH, SOAP, BEEP, TLS — в статье есть пример с ssh.

        Почему убивает XML? Вы же не руками будете его писать. А сам по себе он неплох, если нужно передать структурированную информацию. Ну написали бы Вы (или просто взяли) другой протокол — его что, не нужно парсить и генерировать?
          0
          Мне, и вправду, всё равно какой из обёрток пользоваться, не в этом суть.

          Вопрос был как конкретно засунуть достаточно объёмный xml-запрос в ssh сессию? Сливая всё в одну строку или экранировать «Enter»? Или же вообще писать запрос в файлике и устанавливать «одноразовые» ssh-сессии сразу передавая в них содержимое файла с xml-запросом в качестве набора команд?

          И почему это я не буду его руками писать? А что вы называете не руками? Что можно в каком-нить xml редакторе, используя схему, упростить сие действие?.. Так это не называется «не руками».
            +1
            XML нечувствителен к переходу на новую строку между тегами. Переход делается только для красоты и простоты восприятия людьми.

            Вы настраиваете сетевые устройства по SNMP вручную с помощью snmpset?
            Или же вы используете некую обертку для SNMP, или даже самого CLI устройства?

            Для настройки и траблшутинга я пользуюсь CLI устройства. Для мониторинга и автоматизации — SNMP и NETCONF. Под автоматизацией я понимаю скрипт на любимом языке программирования, который генерит и обрабатывает XML, общаясь с устройствами по NETCONF over SSH.

            Так же в момент написания и отладки в Junos можно сделать " | display xml".
              0
              Вот теперь я вас полностью понял.
              Да, для настройки никогда не юзал snmp, CLI устройства явно удобнее, а зачастую проще у себя конфиг состряпать и дальше по tftp залить на устройство
                0
                SNMP, в основном, используется для автоматической настройки устройств скриптами. При достаточно большом количестве оборудования, редактировать конфиги руками или настраивать железо с помощью Command Line становится слишком трудоемким развлечением.
          0
          SNMP меньше убивает?
          И как вы предпочитаете писать запрос?
            0
            Однострочной командой — параметры, ключи и всё прочее родное…
              0
              В CLI устройства или однострочным OID SNMP?
                0
                Предпочту CLI. Но при этом, необходима возможность отправить туже CLI команду удаленно, а не коряво через snmp (наподобие ssh ${some_devices} ${some_cli_command}).
                  0
                  Как раз команды CLI с некой программной оберткой, проще, по-моему, сделать с помощью NETCONF. Проблемы SNMP и плюсы NETCONF я попытался изложить выше.
          +1
          Не могу вспомнить откуда цитата:
          The S in SNMP is one of the biggest lies in the long line of lies involving the letter S as the first letter of so many protocols.

          А как у NETCONF с модулями для разных языков? У SNMP-то есть, например, для перла, который ставится и используется достаточно просто.
            0
            А зачем нужен модуль NETCONF для языка, если для транспорта используются определенные протоколы (в данный момент 4, один из которых ssh)?
            Язык должен уметь SSH и XML :)
              0
              Наверное имеется ввиду обёртка для непрограммистов (вроде меня), которым чем проще — там лучше.
                +1
                Обертка для SSH, думаю, есть в большинстве языков из тех, для которых есть и SNMP. Для perl, python, ruby точно есть.
            0
            про хокку в JunOS улыбнуло :)
              +2
              > show version and haiku
              Hostname: censored
              Model: mx80
              JUNOS Base OS boot [11.4R1.14]
              JUNOS Base OS Software Suite [11.4R1.14]
              JUNOS Kernel Software Suite [11.4R1.14]
              JUNOS Crypto Software Suite [11.4R1.14]
              JUNOS Packet Forwarding Engine Support (MX80) [11.4R1.14]
              JUNOS Online Documentation [11.4R1.14]
              JUNOS Routing Software Suite [11.4R1.14]

              IS-IS screams,
              BGP peers are flapping:
              I want my mommy!

              :)
              0
              перевод?
                0
                Никак нет, самописная статья.
                  0
                  отлично. Просто 1-в-1 видел на английском, и интересно, какой вариант был раньше.

              Only users with full accounts can post comments. Log in, please.