Если тип операции не задан, то новая конфигурация будет вмёржена в старую. Задать операцию по умолчанию можно с помощью параметра <default-operation>: merge, replace, none.

В дереве <configuration> задаётся собственно целевая конфигурация в виде XML.

Безусловно, самая интересная операция внутри <edit-config> — это replace. Ведь она предполагает, что устройство возьмёт конфигурацию из RPC и заменит ею ту, что находится в datastore. А где-то там под капотом и крышкой блока цилиндров система сама просчитает дельту, которую нужно отправить на чипы.

Практика edit-config

Давайте сначала что-то простое: поменяет hostname:

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
   <target>
     <candidate/>
   </target>
   <config>
     <configuration>
       <system>
          <host-name>just-for-lulz</host-name>
       </system>
     </configuration>
   </config>
  </edit-config>
</rpc>
]]>]]>


Проверяем, что в кандидат-конфиге эти изменения есть, а в текущем — нет

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
   <source>
     <candidate/>
   </source>
   <filter type="subtree">
     <configuration>
       <system>
          <host-name/>
       </system>
     </configuration>
   </filter>
  </get-config>
</rpc>
]]>]]>

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/14.1R1/junos" message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:changed-seconds="1644719855" junos:changed-localtime="2022-02-13 02:37:35 UTC">
    <system>
        <host-name>just-for-lulz</host-name>
    </system>
</configuration>
</data>
</rpc-reply>
]]>]]>


Проверяем running:

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

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/14.1R1/junos" message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:commit-seconds="1644637011" junos:commit-localtime="2022-02-12 03:36:51 UTC" junos:commit-user="eucariot">
    <system>
        <host-name>kzn-spine-0</host-name>
    </system>
</configuration>
</data>
</rpc-reply>


Значит, надо закоммитить изменения.

<rpc>
  <commit/>
</rpc>
]]>]]>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/14.1R1/junos">
<ok/>
</rpc-reply>


Проверяем running:

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

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/14.1R1/junos" message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:commit-seconds="1644720065" junos:commit-localtime="2022-02-13 02:41:05 UTC" junos:commit-user="eucariot">
    <system>
        <host-name>just-for-lulz</host-name>
    </system>
</configuration>
</data>
</rpc-reply>


На Juniper доступны в NETCONF те же функции коммитов, что и в CLI. Например, commit confirmed и confirmed-timeout.

А теперь что-то посложнее и с операцией replace: заменим список BGP-пиров:

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
   <target>
     <candidate/>
   </target>
   <config>
     <configuration>
    <protocols>
            <bgp operation="replace">
                <group>
                    <name>LEAFS</name>
                    <type>external</type>
                    <import>ALLOW</import>
                    <family>
                        <inet>
                            <unicast>
                            </unicast>
                        </inet>
                    </family>
                    <export>EXPORT</export>
                    <neighbor>
                        <name>169.254.0.0</name>
                        <peer-as>64513.00000</peer-as>
                    </neighbor>
                </group>
                <group>
                    <name>EDGES</name>
                    <type>external</type>
                    <import>ALLOW</import>
                    <family>
                        <inet>
                            <unicast>
                            </unicast>
                        </inet>
                    </family>
                    <export>EXPORT</export>
                    <neighbor>
                        <name>222.222.222.0</name>
                        <peer-as>65535</peer-as>
                    </neighbor>
                </group>
            </bgp>
        </protocols>
     </configuration>
   </config>
  </edit-config>
</rpc>
]]>]]>


Коммит

<rpc>
  <commit/>
</rpc>
]]>]]>


Проверяем running

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

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/14.1R1/junos" message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:commit-seconds="1644720678" junos:commit-localtime="2022-02-13 02:51:18 UTC" junos:commit-user="eucariot">
    <protocols>
        <bgp>
            <group>
                <name>LEAFS</name>
                <neighbor>
                    <name>169.254.0.0</name>
                    <peer-as>64513.00000</peer-as>
                </neighbor>
            </group>
            <group>
                <name>EDGES</name>
                <neighbor>
                    <name>222.222.222.0</name>
                    <peer-as>65535</peer-as>
                </neighbor>
            </group>
        </bgp>
    </protocols>
</configuration>
</data>
</rpc-reply>


Всё сработало)

А теперь попробуем операцию merge при добавлении нового пира.

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
&nbsз <edit-config>
   <target>
     <candidate/>
   </target>
   <config>
     <configuration>
    <protocols>
            <bgp operation="merge">
                <group>
                    <name>LEAFS</name>
                    <type>external</type>
                    <import>ALLOW</import>
                    <family>
                        <inet>
                            <unicast>
                            </unicast>
                        </inet>
                    </family>
                    <export>EXPORT</export>
                    <neighbor>
                        <name>169.254.0.0</name>
                        <peer-as>64513.00000</peer-as>
                    </neighbor>
                </group>
                <group>
                    <name>EDGES</name>
                    <type>external</type>
                    <import>ALLOW</import>
                    <family>
                        <inet>
                            <unicast>
                            </unicast>
                        </inet>
                    </family>
                    <export>EXPORT</export>
                    <neighbor>
                        <name>222.222.222.0</name>
                        <peer-as>65535</peer-as>
                    </neighbor>
                    <neighbor>
                        <name>169.254.100.0</name>
                        <peer-as>65535</peer-as>
                    </neighbor>
                </group>
            </bgp>
        </protocols>
     </configuration>
   </config>
  </edit-config>
</rpc>
]]>]]>


Коммит

<rpc>
  <commit/>
</rpc>
]]>]]>


Проверка:

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/14.1R1/junos" message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:commit-seconds="1644721481" junos:commit-localtime="2022-02-13 03:04:41 UTC" junos:commit-user="eucariot">
    <protocols>
        <bgp>
            <group>
                <name>LEAFS</name>
                <neighbor>
                    <name>169.254.0.0</name>
                    <peer-as>64513.00000</peer-as>
                </neighbor>
            </group>
            <group>
                <name>EDGES</name>
                <neighbor>
                    <name>222.222.222.0</name>
                    <peer-as>65535</peer-as>
                </neighbor>
                <neighbor>
                    <name>169.254.100.0</name>
                    <peer-as>65535</peer-as>
                </neighbor>
            </group>
        </bgp>
    </protocols>
</configuration>
</data>
</rpc-reply>
]]>]]>


Вот он новенький пир, и старые на месте.
То есть достаточно очевидна разница между работой replace и merge.

Operation replace

С replace следует иметь в виду некоторые нюансы. Например, что нужно передавать полную конфигурацию того или иного сервиса или функциональности — не просто новые параметры — ведь железка натурально заменит то, что было, тем, что прилетело. Едва ли вы хотите создав один интерфейс в OSPF Area, удалить остальные?
Некоторые сущности не могут быть удалены, такие, например, как физические интерфейсы. Поэтому при формировании соответствующего блока конфигурации нужно быть аккуратнее — в целевой конфигурации должны все они присутствовать, иначе в лучшем случае вернётся <rpc-error>, а в худшем вы чего-то поудаляете.

Использовать replace можно как на уровне отдельных частей конфигурации, так и на верхнем уровне, требуя заменить всё поддерево.

Однако ещё один нюанс заключается в том, что в зависимости от реализации вычисление дельты может занять много ресурсов CPU. Поэтому, если собираетесь кинуть диф на 13 000 строк политик BGP, то дважды подумайте и трижды оттестируйте, что после этого происходит с коробкой.

<commit>

Ещё одно свидетельство того, что модель NETCONF скалькирована с API Juniper — это возможность commit’a candidate-конфигурации в running. Доступна она, конечно, только в том случае, если при обмене capability сервер сообщил, что поддерживает candidate datastore.
<commit> не замещает running на candidate, как это делает <copy-config>, а выполняет именно применение конфигурационной дельты, как это происходит в CLI.

Как и в CLI у commit может быть параметр confirmed, заставляющий откатить изменения, если commit не был подтверждён. За это отвечает отдельная capability: confirmed-commit.

<commit> не входит в число базовых операций, поскольку как раз зависит от поддерживаемых возможностей сервера.

<copy-config>

Операция заменяет одну конфигурацию другой. Имеет два параметра: source — откуда — и target — куда.
Может использоваться как для применения новой конфигурации на коробку, так и для бэкапа активной.
Если коробка поддерживает capability :url, то в качестве source и/или target может быть указан URL.

<delete-config>

Очевидно, удаляет конфигурацию из target datastore. Без хитростей.

<lock/unlock>

Аналогично Juniper CLI ставит блок на target datastore от совместного редактирования, чтобы не было конфликта. Причём блок должен работать как на NETCONF, так и на другие способы изменения конфигурации — SNMP, CLI, gRPC итд.

<close-session>

Аккуратно закрывает существующую NETCONF-сессию, снимате локи, высвобождает ресурсы.

<kill-session>

Грубо разрывает сессию, но снимает локи. Если сервер получил такую операцию в тот момент, когда он дожидается confirmed commit, он должен отменить его и откатить изменения к состоянию, как было до установки сессии.

Инструменты разработчика для NETCONF

Ну вот как будто бы необходимый базис по NETCONF набрали.
Я в этой статье не ставлю перед собой задачу выстроить какую-то систему автоматизации. Просто хочу показать разные интерфейсы в теории и на практике.

И я думаю, к этому моменту вам уже очевидно, что отправка XML через SSH с ручным проставлением Framing Marker (]]>]]>) — не самый удобный способ. Давайте посмотрим на существующие библиотеки.

netconf-console

Прежде чем писать какой-то код, обычно стоит проверить всё руками. Но вот руками крафтить XML и проставлять framing marker’ы тоскливо. Тут отца русской автоматизации спасёт netconf-console — главный и, возможно, единственный CLI-инструмент для работы с NETCONF.

Может работать в режиме команды:

netconf-console --host 192.168.1.2 --port 22 -u eucariot -p password --get-config


А может в интерактивном:
netconf-console2 --host 192.168.1.2 --port 22 -u eucariot -p password -i
netconf> hello


Чуть больше про библиотеку у Романа Додина.

NCclient

Это, пожалуй, самая известная библиотека для работы с NETCONF. Она для питона и достаточно зрелая.
Начать пользоваться очень легко:

from ncclient import manager
 
 
if __name__ == "__main__":
    with manager.connect(
        host="kzn-spine-0.juniper",
        ssh_config=True,
        hostkey_verify=False,
        device_params={'name': 'junos'}
    ) as m:
        c = m.get_config(source='running').data_xml
 
    print(c)


Дабы уберечь читателя от многочасовых мук с отладкой аунтентификации, небольшая подсказка тут.
Текущая версия paramiko на момент написания статьи (>=2.9.0), которую подтягивает ncclient, в ряде случае не может работать с OpenSSH-ключами и падает с ошибкой «Authentication failed». Рекомендую в этом случае устанавливать 2.8.0.
На гитхабе открыта куча issue на эту тему. И, кажется, его даже починили, но я не проверял.
И вроде бы даже есть решение, но и это я не проверял.

Так же работают filter:

from ncclient import manager
 
 
rpc = """
     <filter>
     <configuration>
       <system>
          <host-name/>
       </system>
     </configuration>
     </filter>
     """
 
if __name__ == "__main__":
    with manager.connect(
        host="kzn-spine-0.juniper",
        ssh_config=True,
        hostkey_verify=False,
        device_params={"name": "junos"}
    ) as m:
        c = m.get_config("running", rpc).data_xml
 
    print(c)


С таким вот результатом:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="urn:uuid:864dd143-7a86-40ca-8992-5a35f2322ea0">
  <data>
    <configuration commit-seconds="1644732354" commit-localtime="2022-02-13 06:05:54 UTC" commit-user="eucariot">
      <system>
        <host-name>
        kzn-spine-0
        </host-name>
      </system>
    </configuration>
  </data>
</rpc-reply>


На текстовый XML смотреть не надо — парсим библиотечкой xmltodict:

from ncclient import manager
import xmltodict
 
 
rpc = """
     <filter>
     <configuration>
       <system>
          <host-name/>
       </system>
     </configuration>
     </filter>
     """
 
if __name__ == "__main__":
    with manager.connect(
        host="kzn-spine-0.juniper",
        ssh_config=True,
        hostkey_verify=False,
        device_params={"name": "junos"}
    ) as m:
        result = m.get_config("running", rpc).data_xml
    result_dict = xmltodict.parse(result)
    print(f'hostname is {result_dict["rpc-reply"]["data"]["configuration"]["system"]["host-name"]}')


С уже таким результатом:

hostname is kzn-spine-0


При работе с сетевыми коробками по NETCONF xmltodict, пожалуй, самая практичная библиотека, преобразующая XML-данные в объект Python. Она использует C-шный парсер pyexpat, так что недостатков у такого подхода фактически нет.

Точно так же можно обновить конфигурацию в два действия: <edit_config> в <candidate> и <commit>:

from ncclient import manager
import xmltodict
 
 
rpc = """
     <config>
       <configuration>
         <interfaces>
           <interface>
             <name>ge-0/0/0</name>
             <description>Mit der Dummheit kämpfen Götter selbst vergebens.</description>
           </interface>
         </interfaces>
       </configuration>
     </config>
     """
 
if __name__ == "__main__":
    with manager.connect(
        host="kzn-spine-0.juniper",
        ssh_config=True,
        hostkey_verify=False,
        device_params={"name": "junos"}
    ) as m:
        result = m.edit_config(target="candidate", config=rpc).data_xml
        m.commit()
    result_dict = xmltodict.parse(result)
    print(result_dict)
 
OrderedDict([('rpc-reply', OrderedDict([('@message-id', 'urn:uuid:93bde991-81f9-42d6-a343-b4fc267646c2'), ('ok', None)]))])


Дальше пока копать не будем. Тем более, бытует мнение «без всяких сомнений, самый ублюдочно написанный Python код, что я видел в opensource»

scrapli-netconf

NCclient был первым и классным, но отсутствие поддержки async в нём сильно ограничивает его использование.
Тут нас выручает Карл Монтанари, который уже подарил миру scrapli.
Но для тех, кто достаточно смел, чтобы использовать на своей сети NETCONF, создали scrapli-netconf.

Давайте взглянем на пару примеров работы.

from scrapli_netconf.driver import NetconfDriver
 
 
rpc = """
     <filter>
     <configuration>
       <system>
          <host-name/>
       </system>
     </configuration>
     </filter>
     """
 
device = {
        "host": "kzn-spine-0.juniper",
        "auth_strict_key": False,
        "port": 22
        }
 
if __name__ == "__main__":
    with NetconfDriver(**device) as conn:
        response = conn.get_config("running", rpc)
 
    print(response.result)


Scrapligo и scrapligo-netconf

Для Go тоже не придумано ничего лучше, чем scrapligo, в котором есть модуль для работы через netconf.
Так что если вы сетевик, осваивающий Го, путь для вас уже проложен.

Как это использовать

Мониторинг

NETCONF предоставляет возможность собирать операционные данные:

• Состояния протоколов (OPSF, BGP-пиринги)
• Статистику интерфейсов
• Утилизацию ресурсов CPU
• Таблицы маршрутизации
• Другое

При этом возвращаются структурированные данные, с которыми легко работать без сложных процедур парсинга.
Поэтому NETCONF вполне можно использовать для целей мониторинга.
Тут вы спросите: а зачем, если есть SNMP? А я отвечу. Точнее постараюсь.

• Используем безопасный SSH, не используем SNMP
• Не несём дополнительные протоколы в сеть
• Полная свобода того, какие данные мы собираем, без необходимости разбираться в OID’ах и MIB’ах.
• Гипотетическая возможность оформить подписку на события в системе

Выполнение отдельных операций

Используя NETCONF, можно выполнять какие-то конкретные задачи: собрать данные с сети или изменить какую-то часть конфигурации.
Например, вы хотите периодически собирать MAC-адреса с сети или список коммитов.
Или вам нужно переключать порт коммутатора в другой VLAN.
Или например, у вас есть скрипт, который проверяет, что устройство в порядке — правильные настройки сислог-сервера, корректное время и пинги, куда полагается, работают.
Это всё можно сделать и на парсинге CLI, безусловно, но структурированные данные — это структурированные данные.

Configuration Management

Да, это тоже возможно, если

1. Оборудование поддерживает 100% конфигурации через NETCONF
   Увы, я на своём веку повидал ситуаций, когда некоторые секции просто-напросто отсутствовали в NETCONF и никакого способа настроить нужную функцию нет.
2. Оборудование честно поддерживает операцию «replace», без этого вычисление конфигурационной дельты ложится вновь на сетевиков.

Однако, в том виде, в котором мы познакомились с темой на данный момент, дальше начинается Jinja-программирование. Каждому, кто этим занимался, обычно неловко, и он стыдливо избегает разговора на эту тему.
Задача решается примерно следующим образом:

1. Пишем циклопические развесистые jinja-шаблоны с ифами и форами, внутри которых XML. Шаблоны под каждого вендора, конечно, свои собственные, поскольку и схемы данных у них разные. Но при этом они универсальные в плане ролей устройств — не нужно для свитчей доступа и маршрутизаторов ядра писать разные шаблоны — просто в зависимости от роли будут активироваться те или иные их части.
   Здесь в нужных местах сразу описаны типы операций — где merge, где replace.
2. Каким-то образом формируем под каждое устройство файлы переменных, в которых указаны хостнеймы, IP-адреса, ASN, пиры и прочие специфические вещи. Эти файлы переменных в свою очередь, напротив, вендор-нейтральны, но будут отличаться от роли к роли.
3. Рендерим конфигурацию в формате XML, накладывая переменные на шаблоны. Получаем целевую конфигурацию в виде дерева XML, где в нужных местах проставлена операция replace.
4. Этот XML с помощью ncclient, ansible, scrapli-netconf или чего-то ещё подпихиваем на коробку.
5. NETCONF-сервер на коробке получает RPC и вычисляет конфигурационный патч, который фактически применит. То есть он находит разницу между целевой конфигурацией в RPC и текущей в <running>. Применяет эту конфигурацию.

Как бы это могло выглядеть я уже показывал в предыдущем выпуске АДСМ.

Источник: dteslya.engineer/network_automaiton_101/

Ручная правка файлов переменных — это очень неудобно, конечно же. Просто мрак, если мы говорим про какие-то типовые вещи, как например датацентровые регулярные топологии. Новая пачка стоек — сотни и тысячи строк для копипащения и ручного изменения. Но на самом деле их можно создавать автоматически на основе данных из централизованной базы данных — DCIM/IPAM.

Почему я об этом говорю так уверенно?
Потому что мы у себя (в Яндексе) полностью построили весь жизненный цикл отдельного сегмента сети на основе описанной схемы. И любые изменения на сеть могут применяться только через подобный конвейер и NETCONF. Любые временные конфигурации на железе перетрутся следующим же релизом.

Что тут хорошо:

1. Изменения в Jinja-шаблонах версионируются через git и проходят проверку другими инженерами перед применением. Это систематические изменения, влияющие на большое количество устройств.
2. Изменения в переменных — точно так же. Это точечное изменение конкретного устройства.
3. Только после согласования изменений в пунктах выше, можно сгенерировать новую конфигурацию и далее уже её отправить на проверку в git.
4. Если соблюдать процесс, то отсутствует конфигурационный дрейф.

Что тут плохо?

1. Ну, очевидно, Jinja-программирование
2. Работа с текстом, вместо объектов языка.
3. Отсутствие возможности взглянуть на конфигурационный диф до его применения.

На этом на самом деле заканчивается первая большая часть этой статьи, которая позволяет просто уже взять и получать пользу от NETCONF в задачах автоматизации.

Я вот прям серьёзно сейчас, ей богу! Не туманные абстракции — берём NETCONF — и на многих вендорах уже можно с ним работать выстраивая автоматизацию того или иного объёма.

Как вам ощущения от составления XML? А представьте, что вам нужно всю конфигурацию на несколько тысяч строк описать? А приправить это всё Jinja-программированием? А описывать в ямлах переменные?
Но абсолютное большинство тех, кто использует сегодня NETCONF, именно так и делают. (!) Мнение автора. Change my mind!
В то время как есть YANG и набор инструментов вокруг него?

Хух. Давайте просто не будем об этом сейчас? Просто не сейчас? Попозже. После RESTCONF и gRPC?

RESTCONF

Просто пара слов об этом мертворожденном протоколе.
Это помесь RESTAPI и NETCONF, которая была призвана упростить управление сетью для WEB-приложений.
Внутри идеологически это NETCONF с его datastores и способами работать с конфигурацией, однако в качестве транспорта — HTTP с набором операций CRUD, реализованных через стандартные методы (GET, POST, PUT, PATCH, DELETE).
Данные передаются в формате JSON или XML.
В качестве модели данных используется YANG.

Описан в RFC8040.

Не могу отказать себе в удовольствии попробовать.
Возьмём на этот раз Arista veos-4.21.

Что нужно настроить, чтобы заработал restconf:

1. Выпускаем самоподписанный сертификат

   security pki certificate generate self-signed restconf.crt key restconf.key generate rsa 2048 parameters common-name restconf
certificate:restconf.crt generated


2. Разрешаем доступ на устройство по порту 6020 — правим control-plane acl
   • Смотрим то, что разрешено сейчас — это readonly acl.

     show ip access-lists default-control-plane-acl


   • Копируем правила и создаём копию ACL. Добавляем правило, разрешающее доступ по порту 6020

     ip access-list control-plane-acl-with-restconf
9 permit tcp any any eq 6020
30 permit udp any any eq bfd ttl eq 255
40 permit udp any any eq bfd-echo ttl eq 254
50 permit udp any any eq multihop-bfd
60 permit udp any any eq micro-bfd
70 permit ospf any any
80 permit tcp any any eq ssh telnet www snmp bgp https msdp ldp
90 permit udp any any eq bootps bootpc snmp rip ntp ldp
100 permit tcp any any eq mlag ttl eq 255
110 permit udp any any eq mlag ttl eq 255
120 permit vrrp any any
130 permit ahp any any
140 permit pim any any
150 permit igmp any any
160 permit tcp any any range 5900 5910
170 permit tcp any any range 50000 50100
180 permit udp any any range 51000 51100
190 permit tcp any any eq 3333
200 permit tcp any any eq nat ttl eq 255
210 permit tcp any eq bgp any
220 permit rsvp any any


   • Применяем ACL на Control-Plane

     control-plane
ip access-group control-plane-acl-with-restconf in


4. Включаем сервис RESTCONF

   management api restconf
transport https test
ssl profile restconf


5. Настраиваем SSL

   management security
ssl profile restconf
certificate restconf.crt key restconf.key


6. Вы божественны

Теперь проверяем, что порт открыт

nc -zv bcn-spine-1.arista 6020
Connection to bcn-spine-1.arista 6020 port [tcp/*] succeeded!


И собственно курлим:

curl -k -s GET 'https://bcn-spine-1.arista:6020/restconf/data/openconfig-interfaces:interfaces/interface=Management1' \
--header 'Accept: application/yang-data+json' \
-u eucariot:password

Так мы извлекли информацию про интерфейс Management1.

А вот так можно получить данные по BGP:

curl -k -s GET 'https://bcn-spine-1.arista:6020/restconf/data/network-instances/network-instance/config/protocols' \
--header 'Accept: application/yang-data+json' \
-u eucariot:password | jq


Строка URL формируется следующим образом:

https://<ADDRESS>/<ROOT>/data/<[YANG-MODULE]:CONTAINER>/<LEAF>/[?<OPTIONS>]


• <ADDRESS> — адрес RESTCONF-сервера.
• <ROOT> — Точка входа для запросов RESTCONF. Можно найти тут : https://<ADDRESS>/.well-known/
• data — прям так и остаётся
• <[YANG MODULE:]CONTAINER> — Базовый контейнер YANG. Наличие YANG Module — не обязательно.
• <LEAF> — Отдельный элемент в контейнере
• <OPTIONS> — Опциональные параметры, влияющие на результат.

Пробуем выяснить <ROOT>:

curl -k https://bcn-spine-1.arista:6020/.well-known/host-meta
<XRD xmlns=’http://docs.oasis-open.org/ns/xri/xrd-1.0’>
    <Link rel=’restconf’ href=’/restconf’/>
</XRD>


Ну можно и настроить что-нибудь:
К примеру hostname.

curl -k -X PUT https://bcn-spine-1.arista:6020/restconf/data/system/config \
-H 'Content-Type: application/json' -u eucariot:password \
-d '{"openconfig-system:hostname":"vika-kristina-0"}'

Проверим?

curl -k -X GET https://bcn-spine-1.arista:6020/restconf/data/system/config \
--header 'Accept: application/yang-data+json' \
-u eucariot:password

{"openconfig-system:hostname":"bcn-spine-1","openconfig-system:login-banner":"","openconfig-system:motd-banner":""}


Что? Не поменялось?! И оно действительно не поменялось. Я не смог заставить это работать.

В общем знакомство с RESTCONF пока скорее травматично: документации исчезающие мало, большая часть ссылок — на космические корабли, бороздящие просторы неизученной Вселенной, примеры работы с RESTCONF все как один однообразны, а некоторые просто не работают. С той же аристой использование разных моделей — ietf, openconfig приводит к одному ответу в виде OpenConfig.
В конце концов отсутствие в выдаче хоть сколько-то серьёзных работ по автоматизации с помощью RESTCONF говорит о том, что это всё не более чем баловство. И я намеренно не пишу слово «пока». Лично я в него не верю

Хотя ощутимые удобства присутствуют — это использование чуть более привычного интерфейса и существующих библиотек. И с точки зрения разработчика несколько проще — он теперь имеет дело со знакомым с пелёнок WEB-сервисом.
При этом CRUD не очень гладко ложится на RPC-подход, да и в идее держать открытым на сетевом железе HTTP есть что-то противоестественное, согласитесь?

Просто жаль сил, вложенных в этот протокол. Потому что на пятки ему наступает gRPC/gNMI.

На самостоятельное изучение: RESTCONF intro with Postman — Part 1.

Call-Home

RFC8071

Это, что называется, звонок домой — способ инициировать соединение с NETCONF/RESTCONF-сервера к клиенту, то есть с сетевой коробки на систему управления.

На устройстве настраивается IP-адрес NETCONF/RESTCONF-клиента, куда оно отсылает периодически данные по своему состоянию. Либо обращается для того, чтобы зарегистрироваться в системе и забрать свою конфигурацию.

Применимо для сценариев, когда

• Новое устройство должно сообщить о себе в систему управления
• Устройство находится за NAT или фаерволом
• Администратор считает, что безопаснее иметь закрытые порты на сетевых элементах и открывать только well-known порт на системе управления

Подробно тут останавливаться не будем.

gRPC/gNMI

За последние лет семь gRPC уже всем уши прожужжали. И только самые ловкие разработчики могли избежать реализации взаимодействия с какой-нибудь системой по gRPC.

g в gRPC, кстати, означает вовсе не «google».

Реализация фреймворка поверх gRPC в мире сетевой автоматизации получила название gNMI — gRPC Network Management Interface.
В основе gNMI лежит gRPC, для моделирования данных использует YANG (но не обязательно), внутри уже определяются конкретные RPC. Кроме того gNMI изначально предоставляет возможность естественным образом реализовать telemetry — потоковую передачу телеметрических данных.

В любом случае я не я, если перед gNMI я не разберу gRPC. Поэтому простите за отступление, но без него статья превратится в бесполезное поверхностное хауту.

gRPC

Без теории — за ней прошу в первую статью.
В любом случае после голой теории вот только такие ощущения:

Есть, правда, и более последовательная инструкция.

Хотя точно стоит сказать о том, что gRPC использует Protocol Buffers (или коротко protobuf). Термин этот довольно нагруженный:

• это и спецификация, в которой описано, как данные должны выглядеть. Ещё это называется прото-спека.
• это и IDL (Interface Definition Language), позволяющим разным системам друг с другом на одном языке общаться
• это и формат сериализованных данных, в котором информация передаётся между системами
• То есть всего лишь один proto-файл (или их набор), определяет сразу все эти три вещи
• То есть когда вы пишете gRPC-приложение, формирование protobuf — это важнейший шаг.

Пишем ping!

Спецификация

Описываем protobuf:

service Ping {
  rpc SendPingReply (PingRequest) returns (PingReply) {}
}


Сначала определяем сервис — Ping. А в нём есть метод — SendPingReply — это собственно и есть RPC — та самая процедура, которую мы дёрнем удалённо — процедура отправить Ping Reply.
В качестве атрибута она принимает параметр PingRequest, а вернёт ответ PingReply.

А что такое эти PingRequest и PingReply?

message PingRequest {
  string payload = 1;
}


PingRequest — это одно из пересылаемых сообщений между клиентом и сервером.
Так объявляется факт его существования, и его содержимое. В этом случае внутри сообщения передаётся одно поле payload типа string.
payload — это произвольное имя, которое мы можем выбрать, как хотим.
string — определение типа.
1 — позиция поля в сообщении — для нас не имеет значения.

message PingReply {
  string message = 1;
}


Всё точно то же самое. Именем поля может быть даже слово message.

Вот так будет выглядеть полный proto-файл:

syntax = "proto3";
 
option go_package = "go-server/ping";
 
package ping;
 
// The ping service definition.
service Ping {
  // Sends a ping reply
  rpc SendPingReply (PingRequest) returns (PingReply) {}
}
 
// The request message containing the ping payload.
message PingRequest {
  string payload = 1;
}
 
// The response message containing the ping replay
message PingReply {
  string message = 1;
}


То есть именно вот так и выглядит спецификация, описывающая схему данных на обеих сторонах. И сервер и клиент будут использовать один и тот же proto-файл и всегда знать, как разобрать то, что отправила другая сторона. Даже если они написаны на разных языках.

Сохраняем как protos/ping.proto — он будет один для всех.
Ну ладно спецификация есть. И что с ней теперь делать?

А теперь мы напишем пинг-клиент на Python, а пинг-сервер на Go.

gRPC Client

Сгенерированный Код

Создадим директорию python-client.
Далее на основе спецификации сгенерируем код.
Для этого нужно будет установить grpcio-tools.

pip install grpcio-tools


И используя его уже нагенерить нужные классы:

python3 -m grpc_tools.protoc -I protos --python_out=python-client --grpc_python_out=python-client protos/ping.proto


Сразу после этого в каталоге, где мы это выполнили, появятся два файла: ping_pb2.py и ping_pb2_grpc.py — это сгенерированный код.
Если вы зяглянете вовнутрь, то обнаружите там кучу классов. Это классы, реализующие сообщения, сервисы для сервера (PingServicer) и для клиента (PingStub). Там же у класса Ping есть и метод SendPingReply. И куча других штуковин.
Эти файлы нам никогда не придётся менять вручную — мы будем их только импортировать и использовать.

Очевидно, что эти py-файлы это только реализация интерфейса взаимодействия. Ровным счётом ничего тут не говорит, как этот сервис будет работать.
Бизнес-логика описывается уже отдельно — и вот она делается нами.

Пока структура выглядит так:

.
├── ping_client.py
├── ping_pb2.py
└── ping_pb2_grpc.py


Давайте писать gRPC-клиент.

Клиент будет совсем бесхитростным.
В цикле он будет пытаться выполнить RPC SendPingReply на удалённом хосте 84.201.157.17:12345. В качестве аргумента передаём payload, который считали из аргументов запуска скрипта.

В функции run мы устанавливаем соединение к серверу, подключаем stub и выполняем RPC SendPingReply, которому передаём сообщение PingRequest с тем самым payload.

import sys
import time
from datetime import datetime
 
import grpc
 
import ping_pb2
import ping_pb2_grpc
 
 
server = "84.201.157.17:12345"
 
 
def run(payload) -> None:
    with grpc.insecure_channel(server) as channel:
        stub = ping_pb2_grpc.PingStub(channel)
        start_time = datetime.now()
        response = stub.SendPingReply(ping_pb2.PingRequest(payload=payload))
        rtt = round((datetime.now() - start_time).total_seconds()*1000, 2)
    print(f"Ping response received: {response.message} time={rtt}ms")
 
 
if __name__ == "__main__":
    payload = sys.argv[1]
 
    while True:
        run(payload)
        time.sleep(1)


Если запустить его сейчас, клиент вернёт StatusCode.UNAVAILABLE — сервера пока нет, порт 12345 никто не слушает.

Давайте теперь писать

gRPC-сервер

на Go. Я его развернул на облачной виртуалочке, поэтому какое-то время он будет доступен и читателям.

Всё, что делает сервер — получает какую-то строку в payload, добавляет к нему «-pong» и возвращает это клиенту.

Сгенерированный Код
Тут нам тоже понадобится дополнительный код, реализующий интерфейс.
Создаём рабочую директорию go-server, внутри которой ещё ping — для хранения спецификации и кода интерфейса.

protoc --go_out=. --go-grpc_out=. protos/ping.proto


И получается так:

.
├── go.mod
├── go.sum
└── ping
    ├── ping_grpc.pb.go
    ├── ping.pb.go
    └── ping.proto


Дальше сам код сервера. Я его тоже взял из примеров для go.
Мы тут опускаем часть про установку go, protoc, потому что это всё есть в документации grpc.io.

package main
 
import (
    "context"
    "flag"
    "fmt"
    "log"
    "net"
 
    "google.golang.org/grpc"
    pb "ping-server/ping"
)
 
var (
    port = flag.Int("port", 12345, "The server port")
)
 
type server struct {
    pb.UnimplementedPingServer
}
 
func (s *server) SendPingReply(ctx context.Context, in *pb.PingRequest) (*pb.PingReply, error) {
    log.Printf("Received: %v", in.GetPayload())
    return &pb.PingReply{Message: in.GetPayload() + "-pong"}, nil
}
 
func main() {
    flag.Parse()
    lis, err := net.Listen("tcp", fmt.Sprintf("10.128.0.6:%d", *port))
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    s := grpc.NewServer()
    pb.RegisterPingServer(s, &server{})
    log.Printf("server listening at %v", lis.Addr())
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}


Вся бизнес логика описана в функции SendPingReply, ожидающей PingRequest, а возвращающей PingReply, в котором мы отправляем сообщение message: payload + «-pong» (GetPayload). Естественно, там может быть более изощрённая логика.

Ну, а в main мы запускаем сервер на адресе 10.128.0.6.
Почему не на 84.201.157.17, на который стучится клиент? Тут без хитростей — это внутренний адрес ВМ, на который натируются все запросы к публичному адресу.

Я положу его в
.
└── ping-server
    └── main.go


$ go run ping-server/main.go
2022/01/30 04:26:11 server listening at 10.128.0.6:12345


Всё, сервер готов слушать.

Пример сервера на питоне, если хочется попробовать.

Используем сразу asyncio, это же сервер, нельзя тут блочиться.

Для того, чтобы запустить сервер, нужно доставить пакет grpcio

python -m pip install grpcio


Запускаем?

❯ python ping_client.py piu
Ping response received: piu-pong time=208.13ms
Ping response received: piu-pong time=165.62ms
Ping response received: piu-pong time=162.89ms


У-хууу, ё-моё, grpc-заработал!!!!

А давайте теперь попробуем подампать трафик? Я запустил сервер удалённо и снял трафик.

По умолчанию, Wireshark не декодирует HTTP2, давайте научим его?
Analyze -> Decode As.

Вот тут уже видно почти все наши объекты, которые передаются между клиентом и сервером.
pcap-файл.

Кайф!!

Давайте ещё раз проговорим, что мы сделали.

1. Описали спецификацию сервиса — какие методы доступны, какими сообщениями с какими полями они обмениваются.
2. Сгенерировали из этой спецификации код как для сервера на Go, так и для клиента на Python.
3. Написали логику сервера и клиента
4. Клиент сделал вызов удалённого метода на сервере. Список доступных методов мы знаем из proto-файла.
5. Сервер вернул результат работы процедуры клиенту.

Весь код в репозитории.

Итак, разобрались с gRPC. Ну, будем так считать, по крайней мере.

Внутри гугла gRPC удалось адаптировать даже к задачам сети. То есть gRPC стал единым интерфейсом взаимодействия между разными компонентами во всей компании (или одним из — мы не знаем).

gNMI

gNMI довольно новый протокол. Про него нет страницы на вики, довольно мало материалов и мало кто рассказывает о том, как его использует в своём проде.

Он не является стандартом согласно любым организациям и RFC, но его спецификация описана на гитхабе.

Что нам важно знать о нём для начала? gRPC Network Management Interface.
Это протокол управления сетевыми устройствами, использующий gRPC как фреймворк: транспорт, режимы взаимодействия (унарный и все виды стриминга), механизмы маршаллинга данных, прото-файлы для описания спецификаций.

В качестве модели данных он может использовать YANG (а может и не использовать — в протобафы можно же засунуть всё, что угодно. Ну что опять?).

Как того требует gRPC, на сетевом устройстве запускается сервер, на системе управления — клиент. На обеих сторонах должна быть одна спецификация, одна модель данных.

Поскольку это конструкт над gRPC, в нём определены конкретные сервисы и RPC:

servicegNMI{
  rpcCapabilities(CapabilityRequest) returns(CapabilityResponse);
  rpcGet(GetRequest) returns(GetResponse);
  rpcSet(SetRequest) returns(SetResponse);
  rpcSubscribe(streamSubscribeRequest) returns(streamSubscribeResponse);
}


Более наглядное представление полного прото-файла можно увидеть на интерактивной карте, которую нарисовал Роман Додин:

Здесь каждый RPC расписан на сообщения и типы данных, и указаны ссылки на прото-спеки и документацию.
Не могу сказать, что это удобное место для того, чтобы начать знакомиться с gNMI, но вы точно к нему ещё много раз вернётесь, если сядете на gNMI.

Предлагаю попробовать на практике вместо теорий.

Вообще gNMI, как плоть от плоти gRPC не очень удобен для использования человеком. Прото-файлы пиши, код пиши, исполняй. Нельзя как в REST API просто curl отправить и получить текстовый ответ — это вообще известная боль.
Но для gNMI напридумывали клиентов.

И тут google в лучших традициях делает прекрасные инфраструктурные вещи и ужасный пользовательский интерфейс. gNXI, OpenConfig gNMI CLI client.

gNMIc

Нас и тут спасает Роман Додин, поучаствоваший в создании классного клиента gNMI, совместно с Karim Radhouani — gNMIc.

Устанавливаем по инструкции:

bash -c "$(curl -sL https://get-gnmic.kmrd.dev)"


Теперь надо настроить узел.

interface Management1
   ip address 192.168.1.11/24
 
username eucariot secret <SUPPASECRET>
 
management api gnmi
   transport grpc default
 
ip access-list control-plane-acl-with-restconf-and-gnmi
   8 permit tcp any any eq 6030
…
 
control-plane
   ip access-group control-plane-acl-with-restconf-and-gnmi in


Попробуем выяснить capabilities:

gnmic capabilities \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


А в ответ пара экранов текста, полного возможностей:

gNMI version: 0.6.0
supported models:
  - arista-exp-eos-multicast, Arista Networks ,
  - arista-exp-eos, Arista Networks ,
  - openconfig-if-ip, OpenConfig working group, 2.3.0
…
supported encodings:
  - JSON
  - JSON_IETF
  - ASCII


Тут видно, что устройство поддерживает три вида кодирования. Нам интересен JSON.
А так же, несколько десятков моделей данных, как OpenConfig, так и IETF и проприетарные.
Дальше нет времени объяснять, откуда я это взял, просто пробуем собрать IP-адреса всех интерфейсов:

gnmic get \
--path "/interfaces/interface/subinterfaces/subinterface/ipv4/addresses/address/config"\
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


[
  {
    "source": "bcn-spine-1.arista:6030",
    "time": "1969-12-31T16:00:00-08:00",
    "updates": [
      {
        "Path": "interfaces/interface[name=Management1]/subinterfaces/subinterface[index=0]/ipv4/addresses/address[ip=192.168.1.11]/config",
        "values": {
          "interfaces/interface/subinterfaces/subinterface/ipv4/addresses/address/config": {
            "openconfig-if-ip:ip": "192.168.1.11",
            "openconfig-if-ip:prefix-length": 24
          }
        }
      },
      {
        "Path": "interfaces/interface[name=Ethernet3]/subinterfaces/subinterface[index=0]/ipv4/addresses/address[ip=169.254.101.1]/config",
        "values": {
          "interfaces/interface/subinterfaces/subinterface/ipv4/addresses/address/config": {
            "openconfig-if-ip:ip": "169.254.101.1",
            "openconfig-if-ip:prefix-length": 31
          }
        }
      },
      {
        "Path": "interfaces/interface[name=Ethernet2]/subinterfaces/subinterface[index=0]/ipv4/addresses/address[ip=169.254.1.3]/config",
        "values": {
          "interfaces/interface/subinterfaces/subinterface/ipv4/addresses/address/config": {
            "openconfig-if-ip:ip": "169.254.1.3",
            "openconfig-if-ip:prefix-length": 31
          }
        }
      }
    ]
  }
]


Из ответа видно полный путь к каждому интерфейсу, запрошенный путь и результат в модели OpenConfig.

Один ультра-полезный аргумент в gNMIc, это —path «/» — он вернёт просто всё, что может.
Полезен он тем, что можно из вывода пореверсинжинирить где что искать.

gnmic get \
--path "/" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


Ответа будет много.

И оттуда можно понять, что посмотреть конфигурацию BGP-пиров можно, используя путь «/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/config»:

gnmic get \
--path "/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/config" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


[
  {
    "source": "bcn-spine-1.arista:6030",
    "time": "1969-12-31T16:00:00-08:00",
    "updates": [
      {
        "Path": "network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/config",
        "values": {
          "network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/config": {
            "openconfig-network-instance:auth-password": "",
            "openconfig-network-instance:description": "",
            "openconfig-network-instance:enabled": true,
            "openconfig-network-instance:local-as": 0,
            "openconfig-network-instance:neighbor-address": "169.254.1.2",
            "openconfig-network-instance:peer-as": 4228186112,
            "openconfig-network-instance:peer-group": "LEAFS",
            "openconfig-network-instance:route-flap-damping": false,
            "openconfig-network-instance:send-community": "NONE"
          }
        }
      },
      {
        "Path": "network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.101.0]/config",
        "values": {
          "network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/config": {
            "openconfig-network-instance:auth-password": "",
            "openconfig-network-instance:description": "",
            "openconfig-network-instance:enabled": true,
            "openconfig-network-instance:local-as": 0,
            "openconfig-network-instance:neighbor-address": "169.254.101.0",
            "openconfig-network-instance:peer-as": 0,
            "openconfig-network-instance:peer-group": "EDGES",
            "openconfig-network-instance:route-flap-damping": false,
            "openconfig-network-instance:send-community": "NONE"
          }
        }
      }
    ]
  }
]


А такой, чтобы проверить состояние пира: «/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state/session-state»

gnmic get \
--path "/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state/session-state" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


[
  {
    "source": "bcn-spine-1.arista:6030",
    "time": "1969-12-31T16:00:00-08:00",
    "updates": [
      {
        "Path": "network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/state/session-state",
        "values": {
          "network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state/session-state": "ACTIVE"
        }
      },
      {
        "Path": "network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.101.0]/state/session-state",
        "values": {
          "network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state/session-state": "ACTIVE"
        }
      }
    ]
  }
]


И получается, вполне очевидное деление на конфигурационные и операционные данные.

Вот данные по конфигурации ветки system:

gnmic get \
--path "/system/config" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


[
  {
    "source": "bcn-spine-1.arista:6030",
    "time": "1969-12-31T16:00:00-08:00",
    "updates": [
      {
        "Path": "system/config",
        "values": {
          "system/config": {
            "openconfig-system:hostname": "bcn-spine-1",
            "openconfig-system:login-banner": "",
            "openconfig-system:motd-banner": ""
          }
        }
      }
    ]
  }
]


А вот по состоянию:

gnmic get \
--path "/system/state" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


[
  {
    "source": "bcn-spine-1.arista:6030",
    "time": "1969-12-31T16:00:00-08:00",
    "updates": [
      {
        "Path": "system/state",
        "values": {
          "system/state": {
            "openconfig-system:boot-time": "164480684820",
            "openconfig-system:current-datetime": "2022-02-19T13:24:54Z+00:00",
            "openconfig-system:hostname": "bcn-spine-1",
            "openconfig-system:login-banner": "",
            "openconfig-system:motd-banner": ""
          }
        }
      }
    ]
  }
]


Ну, и последний практический пример в этой секции: настроим чего полезного на железке, Set RPC.

Сначала посмотрим значение AS у одного из BGP-пиров:

gnmic get \
--path "/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/config/peer-as" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p passowrd \
--insecure


[
  {
    "source": "bcn-spine-1.arista:6030",
    "time": "1969-12-31T16:00:00-08:00",
    "updates": [
      {
        "Path": "network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/config/peer-as",
        "values": {
          "network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/config/peer-as": 4228186112
        }
      }
    ]
  }
]


Теперь поменяем значение:

gnmic set \
--update-path "/network-instances/network-instance[name=default]/protocols/protocol[name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/config/peer-as" \
--update-value "4228186113" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p passowrd \
--insecure


{
  "source": "bcn-spine-1.arista:6030",
  "timestamp": 1645281264572566754,
  "time": "2022-02-19T06:34:24.572566754-08:00",
  "results": [
    {
      "operation": "UPDATE",
      "path": "network-instances/network-instance[name=default]/protocols/protocol[name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/config/peer-as"
    }
  ]
}


Проверяем ещё раз:

gnmic get \
--path "/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/config/peer-as" \
-a bcn-spine-1.arista:6030 \
-u eucariot \
-p password \
--insecure


[
  {
    "source": "bcn-spine-1.arista:6030",
    "time": "1969-12-31T16:00:00-08:00",
    "updates": [
      {
        "Path": "network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=169.254.1.2]/config/peer-as",
        "values": {
          "network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/config/peer-as": 4228186113
        }
      }
    ]
  }
]


Уиии!
Я чуть не вскочил с места, когда получилось.

А ещё у gNMIc есть автокомплишн.

Ну нам бы сейчас полезно было бы посмотреть на примеры работы с кодом?
Но вместо того, чтобы всё делать руками, воспользуемся готовым инструментом.

Сам gNMIc может быть импортирован как зависимость в Go-программу, поскольку имеет зрелую подсистему API.

pyGNMI

Эта библиотека написана Антоном Карнелюком (и снова русский след). Заметно удобнее всего остального и активно развивается.

Да на неё даже ссылается Arista из своей Open Management.

Соберём capabilities:

#!/usr/bin/env python
 
from pygnmi.client import gNMIclient
import json
 
 
host = ("bcn-spine-1.arista", 6030)
 
if __name__ == "__main__":
    with gNMIclient(target=host, username="eucariot",
                    password="password", insecure=True) as gc:
 
        result = gc.capabilities()
 
    print(json.dumps(result))


По-get-аем что-нибудь:

#!/usr/bin/env python
 
from pygnmi.client import gNMIclient
import json
 
 
host = ("bcn-spine-1.arista", 6030)
 
if __name__ == "__main__":
    paths = ["openconfig-interfaces:interfaces/interface/subinterfaces/subinterface/ipv4/addresses/address/config"]
 
    with gNMIclient(target=host, username="eucariot",
                    password="password", insecure=True) as gc:
 
        result = gc.get(path=paths, encoding='json')
 
    print(json.dumps(result))


Ну и осталось теперь что-то поменять, например, тот же hostname:

#!/usr/bin/env python

from pygnmi.client import gNMIclient
import json
 
host = ("bcn-spine-1.arista", 6030)
 
set_config = [
(
    "openconfig-system:system",
    {
            "config": {
                "hostname": "bcn-spine-1.barista-karatista"
            }
    }
)
]
if __name__ == "__main__":
 
    with gNMIclient(target=host, username="eucariot",
                    password="fpassword", insecure=True) as gc:
 
        result = gc.set(update=set_config)
 
    print(json.dumps(result))


python gc_set.py | jq
{
  "timestamp": 1645326686451002000,
  "prefix": null,
  "response": [
    {
      "path": "system",
      "op": "UPDATE"
    }
  ]
}


В репе ADSM можно найти пример по изменению BGP peer-as.

gNMIc и pyGNMI — это всего лишь частные инструменты для работы через gNMI. Ничто не мешает вам самим реализовать набор методов удобным образом.
Важно здесь заметить то, что у gNMI нет концепции Data Stores и как следствие функционала коммитов конфигурации — мы работаем с сервисом.
gNMI заставляет нас перевернуть привычный взгляд на сеть вверх ногами. Мы к ней теперь должны относиться как к ещё одному сервису, которым можно легко управлять через единообразный интерфейс. Сам же gNMI обеспечивает транзакционность всех изменений, передаваемых в одном RPC.
Представьте себе, что вы пишите в базу данных и нужно потом сделать ещё коммит, чтобы эти изменения сохранить — звучит нелогично. Вот так и с сетью — транзакционность есть, коммитов — нет.
Для инфраструктурной команды сеть — это больше не какой-то свой собственный особенный мир, находящийся где-то там за высокой стеной CLI, окружённый рвами, заполненными проприетарным синтаксисом.

Нам следует разделить сетевое устройство, к которому мы всю жизнь относились как к чему-то в целостному, потому что покупаем сразу всё это в сборе, на следующие части:

• железный хост — коммутаторы и маршрутизаторы, со всеми их медными и оптическими проводочками, куском кремния под вентилятором и трансиверами,
• операционная система — софт, который управляет жизнью железа и запускаемыми приложениями,
• приложения, реализующие те или иные сервисы или доступ к ним — аутентификация, интерфейсы, BGP, VLAN’ы, или gNMI, дающий доступ к ним ко всем.

Да, влияние проблем на сетевом устройстве имеет больший охват. Да, можно оторвать себе доступ одним неверным движением. Да, поддержка целевого состояния на все 100% — всё ещё сложная задача.

Но чем, в конце концов это отличается от обычного Linux’а, на котором крутится сервис?

То есть сервисный интерфейс (gNMI, gRPC, REST, NETCONF) следует рассматривать как способ управления собственно сервисами, в то время как для обслуживания хоста никуда не девается SSH+CLI — для отладки, обновления, управления приложениями. Впрочем и тут есть Ansible, Salt. Вот только идеально для этого, чтобы сетевая железка стала по-настоящему открытой — с Linux’ом на борту.

Кроме того есть

gNOI

gRPC Network Operations Interface от OpenConfig — набор микросервисов, основанных на gRPC, позволяющих выполнять операционные команды на хостах.
Если проще, то можно запустить ping, traceroute, почистить разные таблицы, сделать Route Refresh BGP-соседу, скопировать файл — всё то, что относится не к конфигурации, а скорее к отладке и эксплуатации.

На самом деле там на сегодняшний день уже достаточно внушительный список операций.

А ещё по аналогии с gNMIc существует и gNOIc.

Обратили, кстати, внимание, что здесь в вызовах не было ничего специфичного для Аристы?
На самом деле некая неявная привязка есть — это пути, они могли бы отличаться для Аристы и Хуавэя. Но внимание на слово «openconfig» в этих путях. Что это? Что за Открытый конфиг?

Сложность с автоматизацией сети — она ведь в чём? В том, что прежде чем отправлять конфигурацию на устройство, человек должен сесть и прям-таки разобраться в структуре CLI или XML и руками накидать шаблоны для конфигурации.
Даже просто для того, чтобы настроить IP-адрес на интерфейсе, нужно знать иерархию секций конфигурации или конкретное поддерево XML.

А ещё выяснить, в каком формате надо передавать адрес: fe80::1/64, fe80::1 64, fe80::1 link-local, address: fe80::1, mask: 64, FE8:0:0:0:0:0:0:1, 0000111111101000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000001 или там вообще не поддерживается IPv6. И надо ли сначала как-то энейблить IPv6, а MTU заимствуется с интерфейса или для IPv6 отдельный?
И так для каждого вендора по отдельности. Знаете, сетевых автоматизаторов спасает только то, что они до этого лет 10 ели на завтрак циски да джуниперы — и как свои два пальца знают все тонкости CLI.
Оно же их и губит.

NETCONF поел овса из-за того, что не предложил никакой стандартизации для моделирования данных. Именно поэтому вендоры успели наплодить своих собственных, несовместимых моделей, про которые мы и поговорим ниже.

Модели данных

Собственно то, в какой иерархии представлена конфигурация — и есть модель данных. Говорится об этом или нет, но такая модель есть всегда и у любого интерфейса. Она может быть плоской или иерархической, может быть простой или запутанной. Если бы её не было, то вы бы просто не смогли настроить устройство, а команды конфигурации могли бы видоизвиняться случайным образом. Говорят, в Router OS 7 подвезли такую функцию.

Так, мы знаем, что например, в случае Juniper нужно войти в контекст system->login, чтобы настроить нового пользователя, а формат команды будет set <USERNAME> <OTHER PARAMETERS>.
А настройка IP-адреса управления при этом будет происходить в контексте interface -> em0 -> unit 0 -> family inet. И так будет всегда. Во всяком случае на этой железке и этой версии софта.

То есть модель данных — это контракт между пользователем и операционной системой — как она интерпретирует переданные команды в зависимости от контекста.

Это верно для CLI, SNMP, NETCONF, gNMI и даже прямых вызовов чипового SDK.

Просто бОльшую часть истории нам не нужно было знать об этих моделях. Есть аксиома — у каждого вендора она своя. А мы в голове, сознательно или нет, её выстраивали, воссоздавали.
И вендор может менять эту модель по своему усмотрению от версии к версии. А мы как люди к этому адаптируем свою внутреннюю модель, приспосабливаемся — по законам эволюции.

Native

Так было всегда, но это поменялось с приходом автоматизации. Вендоры, как будто бы думали, что рост сетей можно поддерживать постоянным докидыванием людей на их настройку. Но людям это не нравилось, они начали писать инструменты автоматизации на perl’ах, php, python’ах с expect’ами, попытками отловить все возможные ответы CLI, правильно на них среагировать. Но количество скорби в этом мире только множилось. Все рано или поздно приходили к пониманию, что долго притворяться робот человеком не может.

Так и появились NETCONF и RESTCONF (так появлялся и SNMP). Они дали возможность работать со структурированными данными, а также создавать более явные контракты между клиентом и сервером.
Автор утилиты/библиотеки, опираясь на этот контракт, пишет код, а вендор обязуется принять данные, которые ему прислали. Если вы присылаете соответствующие контракту данные, а вендор говорит, что вы ерунду прислали, вы идёте в суд (в TAC).

Первые реализации NETCONF были настолько же закрытыми, как и сам CLI. У джуна — меньше, у циски — больше. У кого-то RPC перекладывались собственно в вызове CLI.
Но необходимость приводить это всё к каким-то явным схемам становилась всё очевиднее с каждым днём. К этому же подталкивал и расцвет NMS, берущих на вооружение NETCONF.

И так появились первые модели данных — NATIVE. У каждого вендора своя, но уже модель, и уже открытая.
Вендоры с достаточно высокой социальной ответственностью выкладывают свои модели в публичный репозиторий.

Наличие модели позволяет уже как минимум не рыскать в попытках вслепую нащупать, как составить XML, а пойти, посмотреть, в каком виде ожидает данные коробка.
А при желании модель читать программно и руками даже ничего не делать.

Вендор-нейтральные модели

С этим уже можно было жить.
Инженерам нужно было чуть меньше думать об интерфейсах и форматах сообщений, но с глубоким вниманием подходить к содержимому сообщений всё ещё приходилось, оказывая разные знаки почтения разным вендорам.

При этом казалось бы — вся сеть — это конечный набор одинаковых сервисов, если выбросить всякие IGRP, HSRP, RRPP и прочие проприетарные выдумки. Ну, всем же нужен IP, OSPF, BGP? Всем нужна аутентификация на устройствах и SSH? Они не могут иметь очень уж принципиальные отличия, как минимум из-за необходимости поддерживать совместимость друг с другом и соответствия RFC.
Так почему мы делаем это сотней разных способов?

Сложность ведь не в транспорте и не в интерфейсе, а в модели данных. Сделать у каждого вендора Configuration State Management — одноразовая решаемая (а много где и решённая) задача. А вот договориться между всеми производителями, как должна выглядеть модель — так же сложно, как и любая другая задача, где людям нужно договориться.

Но ни один из зарождавшихся и выживших стандартов или не ставил целью унификацию вообще, или пытался поднять этот вопрос, но был выброшен в окно штаб-квартиры вендора.

Хотя вру. IETF предприняли отчасти успешную попытку написать универсальную модель.

IETF-модель

Ещё в 2014-м году были сделаны первые коммиты в её репозиторий.
С тех пор много накоммичено, но мало фактически сделано. Общепризнанно, что IETF -модель очень медленно развивается, у неё низкое покрытие, а архитектура — так себе.
С IETF-модели рекомендуют начинать, потому что она якобы проще, а уже потом переходить на OpenConfig, но как по мне — это напрасная трата времени.
Она мертворождённая и никому особо не нужна. Хотя вендоры поддерживают.
Заказчиков и пользователей беспокоила обрезанность модели и инертность IETF.
Но один в поле не воин — тысячи разрозненных автоматизаторов по всему миру не могли ничего с этим сделать. А вот большие компании могли.
Когда надо настроить тысячу свитчей, а каждый месяц запускать новый датацентр, когда на сети 5 разных поколений дизайна, а катить изменения нужно дважды в день, начинаешь несколько иначе смотреть на все этим ваши сиэлаи и вендор-специфичные эксэмали.

Так гугл придумал OpenConfig. Он не стал размениваться на IETF-модели и торги со стариканами из института.

OpenConfig — мечта, становящаяся явью

Возможно, впервые за шестидесятилетнюю историю телекоммуникаций у нас появился шанс изобрести свой USB Type C. Представьте мир, в котором Cisco, Juniper, Arista и Mikrotik настраиваются одними и теми же командами и это к тому же приводит к одинаковому результату?

Я не могу.

OpenConfig — это открытая YANG-модель, которая предполагается единой для всех вендоров. Одна стандартизированная модель для управления конфигурацией, сбора операционных данных с устройства и телеметрии. Одна для всех поддерживающих OC вендоров.

Итак, OpenConfig появился в 2015 году в Google как ответ на следующие вызовы:

• 20+ ролей сетевых устройств
• Больше полудюжины вендоров
• Множество платформ
• 4M строк в конфигурационных файлах
• 30K изменений конфигураций в месяц
• Больше 8M OIDs опрашиваются каждые 5 минут
• Больше 20K CLI-команд выполняется каждые 5 минут
• Множество инструментов и поколений софта, куча скриптов
• Отсутствие абстракций и проприетарные CLI
• SNMP не был рассчитан на столь большое количество устройств и на столько большие объёмы данных (RIB)

Как работать с openconfig мы уже немного попрактиковались выше.
Полезным было бы взглянуть на структуру этой модели. Но это мы сделаем в следующей главе про YANG.

OpenConfig сегодня даёт возможность настройки базовых сервисов. Безусловно речь не идёт про вещи, завязанные на аппаратные особенности: QoS, управление буферами и ресурсами чипа, сплиты портов, работа с трансиверами. И в каком-то хоть сколько-то обозримом будущем этого ждать не стоит.

Хуже того, на сегодняшний день многие вендоры, ввязавшиеся в поддержку OC, не реализуют все 100%, а лишь часть.

Но BGP с OSPF настроить точно можно.

Что делать в этом случае?

И есть два пути.
Один из них — брать OC и видоизменять его с помощью добавления или убирания каких-либо его частей.
Когда вендор хочет расширить покрытие модели — он делает augmentation, встраивая его в нужное место.
Если он хочет поменять какое-то поведение или удалить функциональность — он описывает deviation к базовой модели.
Этот способ, конечно, не покрывает все потребности.

Другой — использовать вендорские Native модели, покрытие которых намного больше.

Абсолютно нормально совмещать OC и Native — главное, не настраивать одно и то же с помощью разных моделей.
В целом рекомендуют (даже сами вендоры), использовать OC там, где это возможно, а где нет — прибегать к native.

Источник: доклад на Cisco Live

Google привёл в наш мир OpenConfig в одной руке, а gNMI — в другой.
Но в качестве транспорта для OC может быть как gNMI, так и NETCONF и RESTCONF — это не принципиально. В то же время, для gNMI OpenConfig в частности и YANG вообще не единственные возможные модели и языки.

Так что же это за мифический

YANG

Оооо, как долго я шёл к этому, как долго я ждал, чтобы разобраться с этой темой.
Такой манящий и такой недоступный — YANG — Yet Another Next Generation, который решит все мои дилеммы автоматизатора, который снимет с меня груз парсинга CLI и приведёт нас всех в новый дивный мир.
Почему-то казалось, что стоит только понять, что такое YANG — и дальше самой сложной задачей останется оттраблшутить Ансибль и высадиться на Марсе.

YANG, а точнее модели, написанные на нём, не стали серебряной пулей, как не стали ей (пока) NETCONF, OpenConfig, gNMI.

И вообще YANG — вещь весьма академическая. Это просто язык описания моделей. Модели у каждого производителя и под каждую задачу могут быть совершенно разными, но, учитывая, что они все написаны на одном языке, мы можем применять одни и те же подходы и инструменты для работы с ними, и не отращивать ещё новые нейронные связи.

Вообще-то модели может не быть вовсе, или она может быть описана по-английски или по-русски, вместо YANG. Но при этом в JunOS/VRP/IOS по-прежнему будет какая-то структура данных. Просто в этом случае у вас не будет контракта, и в суд вы обратиться не сможете.
Это собственно то, как мы и жили прежде.

Вообще-то YANG пришёл на помощь NETCONF’у, когда стало понятно, что достаточно разврата — откапывайте SNMP SMI без моделей дальше никуда ни шагу — и уже достаточно ошибок было совершено.
YANG — достойный сын SMIng. Когда парни из Network Working Group поняли, что с SNMP у них как-то не выгорело, весь накопленный багаж знаний они пустили на пользу обществу.
В общем-то, не мудрствуя лукаво, ребята из IETF взяли синтаксическую структуру и базовые типы из SMIng и запилили YANG.
При разработке YANG решили не совершать ошибок SMIng, который должен был стать универсальным языком под общие задачи, отчего немало страдал — нет, YANG нацеливался исключительно на NETCONF.
И какова ирония: RESTCONF и gNMI тоже решили использовать YANG — как язык моделирования. Ну логично ведь — не выдумывать 13-й стандарт же (хотя, подождите)?

Но гугл пошёл ещё дальше — gNMI может работать как с YANG-моделями, так и нет. Свободу вариативности! Что, впрочем, вполне логично, ведь в основе gNMI — protobuf’ы gRPC. А они могут как быть созданы на основе YANG-модели, так и просто придуманы из головы, или модель может быть написана не на YANG.

Как видно, благими намерениями уже тогда — был устлан путь к хьюман-ридабл, мэшин-парсибл.

Давайте мы не будем закапываться в сам язык — пожалуй, это нужно не очень большому числу людей. Нам интереснее практическая сторона — конкретные модели, как в них найти глазами нужные вещи, как с ними работать программно, какая вообще от них польза.

Дальше в качестве практики возьмём модель OpenConfig.

Препарируем YANG-модель

Давайте ещё раз вспомним пример, как мы собирали данные по конфигурации интерфейсов.

gnmic -a bcn-spine-1.arista:6030 -u eucariot -p password--insecure get --path "/interfaces/interface/subinterfaces/subinterface/ipv4/addresses/address/config"


Откуда взялся этот замысловатый путь?

Для этого нам понадобится взглянуть на открытый репозиторий OpenConfig.

Пристально смотрим…
Ещё немного…
Понятно?

И мне не очень. Чтобы такое читать, надо всё же разбираться с самим языком.
Нам лень.
Поэтому воспользуемся помощью библиотеки pyang.

Pyang

Продолжим с примером про интерфейсы.

sudo pip install pyang


В рабочий каталог склоним репу:

git clone https://github.com/openconfig/public


И дадим вот такую команду:

pyang -f tree -p yang/oc/public/release/models/ yang/oc/public/release/models/interfaces/openconfig-interfaces.yang


И дальше вываливается много текста:

module: openconfig-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw name             -> ../config/name
        +--rw config
        |  +--rw name?            string
        |  +--rw type             identityref
        |  +--rw mtu?             uint16
        |  +--rw loopback-mode?   boolean
        |  +--rw description?     string
        |  +--rw enabled?         boolean
        +--ro state
        |  +--ro name?            string
        |  +--ro type             identityref
        |  +--ro mtu?             uint16
        |  +--ro loopback-mode?   boolean
        |  +--ro description?     string
        |  +--ro enabled?         boolean
        |  +--ro ifindex?         uint32
        |  +--ro admin-status     enumeration
        |  +--ro oper-status      enumeration
        |  +--ro last-change?     oc-types:timeticks64
        |  +--ro logical?         boolean
        |  +--ro management?      boolean
        |  +--ro cpu?             boolean
        |  +--ro counters
        |     +--ro in-octets?             oc-yang:counter64
        |     +--ro in-pkts?               oc-yang:counter64
        |     +--ro in-unicast-pkts?       oc-yang:counter64
        |     +--ro in-broadcast-pkts?     oc-yang:counter64
        |     +--ro in-multicast-pkts?     oc-yang:counter64
        |     +--ro in-discards?           oc-yang:counter64
        |     +--ro in-errors?             oc-yang:counter64
        |     +--ro in-unknown-protos?     oc-yang:counter64
        |     +--ro in-fcs-errors?         oc-yang:counter64
        |     +--ro out-octets?            oc-yang:counter64
        |     +--ro out-pkts?              oc-yang:counter64
        |     +--ro out-unicast-pkts?      oc-yang:counter64
        |     +--ro out-broadcast-pkts?    oc-yang:counter64
        |     +--ro out-multicast-pkts?    oc-yang:counter64
        |     +--ro out-discards?          oc-yang:counter64
        |     +--ro out-errors?            oc-yang:counter64
        |     +--ro carrier-transitions?   oc-yang:counter64
        |     +--ro last-clear?            oc-types:timeticks64
        +--rw hold-time
        |  +--rw config
        |  |  +--rw up?     uint32
        |  |  +--rw down?   uint32
        |  +--ro state
        |     +--ro up?     uint32
        |     +--ro down?   uint32
        +--rw subinterfaces
           +--rw subinterface* [index]
              +--rw index     -> ../config/index
              +--rw config
              |  +--rw index?         uint32
              |  +--rw description?   string
              |  +--rw enabled?       boolean
              +--ro state
                 +--ro index?          uint32
                 +--ro description?    string
                 +--ro enabled?        boolean
                 +--ro name?           string
                 +--ro ifindex?        uint32
                 +--ro admin-status    enumeration
                 +--ro oper-status     enumeration
                 +--ro last-change?    oc-types:timeticks64
                 +--ro logical?        boolean
                 +--ro management?     boolean
                 +--ro cpu?            boolean
                 +--ro counters
                    +--ro in-octets?             oc-yang:counter64
                    +--ro in-pkts?               oc-yang:counter64
                    +--ro in-unicast-pkts?       oc-yang:counter64
                    +--ro in-broadcast-pkts?     oc-yang:counter64
                    +--ro in-multicast-pkts?     oc-yang:counter64
                    +--ro in-discards?           oc-yang:counter64
                    +--ro in-errors?             oc-yang:counter64
                    +--ro in-unknown-protos?     oc-yang:counter64
                    +--ro in-fcs-errors?         oc-yang:counter64
                    +--ro out-octets?            oc-yang:counter64
                    +--ro out-pkts?              oc-yang:counter64
                    +--ro out-unicast-pkts?      oc-yang:counter64
                    +--ro out-broadcast-pkts?    oc-yang:counter64
                    +--ro out-multicast-pkts?    oc-yang:counter64
                    +--ro out-discards?          oc-yang:counter64
                    +--ro out-errors?            oc-yang:counter64
                    +--ro carrier-transitions?   oc-yang:counter64
                    +--ro last-clear?            oc-types:timeticks64


Неплохо. С такими аргументами pyang представляет модель в виде дерева, выбрасывая несущественные данные.
Здесь сразу видно, на каком уровне иерархии что находится, какой у него тип и режим — rw или ro.
Постойте, но где же ipv4, который в запросе gnmic? Тут его явно нет. А в запросе и ответе явно был — то есть где-то он должен существовать и в модели.
Взглянем ещё раз на директорию. И повторим pyang:

pyang -f tree -p yang/oc/public/release/models/ yang/oc/public/release/models/interfaces/openconfig-if-ip.yang | head -n 10
module: openconfig-if-ip

  augment /oc-if:interfaces/oc-if:interface/oc-if:subinterfaces/oc-if:subinterface:
    +--rw ipv4
       +--rw addresses
       |  +--rw address* [ip]
       |     +--rw ip        -> ../config/ip
       |     +--rw config
       |     |  +--rw ip?              oc-inet:ipv4-address
       |     |  +--rw prefix-length?   uint8


Вот и он во всей красе. И тут видно, что это аугментация к модели /oc-if:interfaces/oc-if:interface/oc-if:subinterfaces/oc-if:subinterface.

А что такое oc-if?

less yang/oc/public/release/models/interfaces/openconfig-interfaces.yang | grep '^ *prefix'
prefix "oc-if";


Итак, у модели есть короткий префикс для более удобного обращения к ней. Он используется в другой модели, чтобы сделать его аугментацию.
Так можно просто проверить корректность

pyang -p yang/oc/public/release/models/ yang/oc/public/release/models/interfaces/openconfig-interfaces.yang


Ключ -f позволяет конвертировать в разные форматы: tree, yin, yang, jstree, uml и другие.
Для нас интереснее всего tree и uml, потому что вот такие крутые картинки можно рисовать для визуалов

Чтобы конвертировать uml в png можно воспользоваться пакетом plantuml.

С помощью pyang, конечно, можно работать не только с моделями OpenConfig, но и с любыми другими, написанными на языке YANG.

Место, где неплохо описан pyang.

А тут бравые парни из Австралии пишут свою модель. С этой работой будет полезно ознакомиться тем, кто хочет разобраться поглубже в языке YANG.

На сегодняшний день многие вендоры поддерживают YANG-схему для своих NETCONF/gNMI-интерфейсов.

Есть несколько мест, где их можно раздобыть:

• Официальный репозиторий YANG.
  Тут есть ссылки на гитхабы вендоров, которые публикуют свои модели.
• Но Huawei, например, хранит свои YANG-и в нескольких местах (https://github.com/Huawei/yang/ и https://github.com/HuaweiDatacomm/yang)
• Отдельно так же лежат схемы аристы: https://github.com/aristanetworks/yang
• Некоторые вендоры могут хранить их на своих сайтах.

В общем, собираем с репы по коммиту.

Замечательная новость в том, что все коробки, заявляющие своё соответствие RFC6022 должны уметь возвращать всю YANG-схему по запросу с операцией <get_schema>.
Отвратительная новость в том, что не все вендоры эту операцию поддерживают.

Что нужно знать про YANG?

Это способ описать структуру данных, но не сами данные.
Сами данные могут быть представлены в любом формате, поддерживающем структуры: XML, JSON, Protobuf, объекты Python.
YANG придумывали не для того, чтобы решить общую задачу, он нацелен на конкретно NETCONF и конкретно XML-кодирование. Но его смогли присобачить и к другим интерфейсам.

Я бы взял на себя смелость сказать, что NETCONF/YANG — это как TCP/IP. То есть там и про NETCONF, и про YANG. Однако не только NETCONF.

Очевидно, YANG — огромная тема, которой будет тесно даже на страницах отдельной книги. В этой статье мне хотелось только приоткрыть первый её разворот, на котором ещё нет пугающих выкладок.
Возможно, когда-то, если я осознаю неизбежность его повсеместного проявления, я напишу отдельную огромную статью и о нём. А пока положим достаточным эти едва ли заметные тропинки.

Model Driven Programmability

Так что же это такое? Ведомая моделью программируемость? Теперь, после двух статей, нам хватит пары минут, чтобы разобраться что это такое.

Давайте вернёмся к 4-й части АДСМ, где я использовал позаимствованную у Дмитрия Тесля картинку.

Источник: dteslya.engineer/network_automaiton_101/

Она ведь очень понятная? Inventory, Git с шаблонами конфигурации, рендер, валидация, применение.

Где закопаны два мешка с человеко-неделями? Под шаблонами с генераторами и под системами применения конфигурации.
Со вторым пытаются бороться NETCONF, RESTCONF, gNMI.
А с первым — модели.

Проблема в том, что шаблоны мы составляем руками на основе изучения документации, интерфейса коробки и действуем методом проб и ошибок, вообще-то. Если нужна проверка типов, диапазонов, если меняется иерархия — будьте добры сами всё это написать и обработать. И, окончив, уехать в сумасшедший дом, учить друзей джинджа-программированию.

Model Driven меняет картину следующим образом:

Не могу найти, откуда брал эту картинку.

Здесь шаблоны конфигурации заменяются на YANG-модель (в данном случае OpenConfig).
Из инвентарки (топологии) и этих моделей рендерится конфиг, который с помощью RPC (тут gRPC) прогружается на коробку.

Model Driven означает тут, что мы

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

Иными словами именно модель управляет тем, как мы и железо будет работать с конфигурацией.
Вот и вся суть.

Всё вместе

Ух, какую же большую кучу из разных технологий и идей мы свалили с начала статьи. Пора бы её разобрать и по коробкам разложить.
Итак,

Транспорт

• SSH,
• HTTP,
• HTTP/2
• SNMP тоже, конечно же, возможен, но не нужен.

Интерфейс

• CLI
• SNMP
• NETCONF
• RESTCONF
• gRPC

Формат данных

• Текст
• XML
• JSON
• Protocol Buffers

Способ описания спецификации — он же может называться схемой

• XSD
• JSON schema
• Protocol Buffers
• MIB
• Проприетарный способ, придуманный вендором и описанный в документации.

YANG-модели данных конфигурации

• OpenConfig
• Проприетарные модели
• IETF
• Проприетарная модель, придуманная вендором и неописанная в документации

Языки описания моделей

• YANG
• SMI/SMIng
• Проприетарный язык, придуманный вендором и не описанный в документации

И ещё другими словами

• YANG — язык моделирования данных, но не сами модели,
• YANG-модели — конкретные модели, написанные на языке YANG, но ещё не сами данные и не их схема,
• OpenConfig — вендор-независимая YANG-модель данных конфигурации сетевого оборудования,
• Native-модели — вендорские проприетарные YANG-модели данных сетевой конфигурации,
• XML, JSON, Protobuf — синтаксис по представлению структур данных в виде, пригодном для передачи (например, строка), иными словами — сериализация,
• XML-схемы (XSD), JSON-схемы, proto-спецификации — репрезентация YANG-модели в соответствующем формате, схема
• NETCONF — протокол взаимодействия с сетевым железом, работающий поверх SSH. В качестве формата данных использует XML. Структура XML может быть основана на YANG-модели, но не обязательно,
• RESTCONF — аналог NETCONF, но работающий через HTTP. Данные представляются в JSON или XML на основе какой-либо YANG-модели,
• gRPC — фреймворк для межсервисного взаимодействия, которые реализует интерфейс, протокол, формат данных и спецификации (protocol buffers). Непосредственно к сетям отношения не имеет,
• Protobuf — он же protocol buffers — спецификация для gRPC, а так же формат передачи данных в нём,
• gNMI — протокол на основе gRPC для взаимодействия с сетевым оборудованием. Всегда основан на модели, представленной в формате protobuf-спецификации, но это не обязательно должна быть YANG-модель.

И чтобы окончательно запутаться разобраться в терминах, давайте разложим по полочкам: схема, спецификация, IDL.
Схема — это широкий термин. Это то, что описывает, как данные должны быть представлены и чему соответствовать: структура, иерархия, типы итд.
Думаю, что слова «схема» и «спецификация» мы можем считать синонимами.
Для каждого формата данных будет так же и свой формат написания схем.
Для XML — это XSD, для JSON — JSON-schema, для gRPC — protobuf.
А уже конкретный файл/текст, описывающий какие-либо данные — это и будет сама схема.

Соответственно данные можно провалидировать по схеме — убедиться, соответствуют ли они ей.
Из схемы/спецификации можно создать объекты языка программировани, чтобы было удобнее работать с ними.
То есть из XML-схемы создаём классы, например, питона, работаем с ними привычным образом, далее преобразуем в XML, который можно уже проверить на соответствие изначальной схеме. Или данные, полученные из какой-то внешней системы, можно проверить на такое соответствие, прежде чем начинать обрабатывать.

IDL — его назначение прямо следует из названия — язык определения интерфейса. Если схема описывает как данные выглядят вообще, то IDL определяет, как две системы должнц представлять данные, чтобы взаимодействовать друг с другом. То есть это уже контракт между ними, а схема — это инструмент, позволяющий этого добиться.
Таким образов в gRPC protobuf является и IDL и способом описания спецификацией. В случае NETCONF формат данных — это XML, способ описания спецификации — это XSD, а в качестве IDL выступает сам NETCONF — ведь именно он и определяет интерфейс.

Модель же определяет то, как будет выглядеть сама спецификация/схема. То есть это ещё более абстрактная конструкция. И нужна модель для того, чтобы на её основе была возможность создать как proto-спеку, так и JSON-схему, так и XSD.

Заключение

Думаю, что хорошее заключение было в первой статье, к которой я и отсылаю читателя.
Путь нас ожидает неблизкий. Туман медленно рассеивается, открывая новые развилки дорожек, из которых нужно выбирать перспективную.
Но вот что следует держать в голове. Нам обо всём этом рассказывают на конференциях и пишут в длинных статьях как о свершившемся факте, в то время, как многие вещи всё ещё не работают, а в конце обычно есть приписка «Adding support of OpenConfig gNMI paves the way for future network automation».

Полезные ссылки

• Как я собирал лабу для данной статьи
• Репозиторий с примерами кода из этой статьи
• Главные RFC:
  • NETCONF: RFC4741, RFC6241
  • RESTCONF: RFC8040
  • YANG: RFC6020, RFC7950
• Концепция RPC: Remote Procedure Call (RPC)
• Про форматы данных: YAML: The Missing Battery in Python
• Детальный разбор XML во всём его многообразии: XML Tutorial
• XML разобран по кусочкам и мило иллюстрирован (русский): Что такое XML
• Understanding XML Namespaces
• Сайт OpenConfig: openconfig.net
• Опубликованные модели OpenConfig
• Хорошая вводная в NETCONF и немного YANG: YANG Data Modelling and NETCONF
• Продолжение про YANG и немного про NETCONF: The Road to Model Driven Programmability
• На русском про NETCONF. Начало
• Если жить не можете, хочется на русском про YANG, и вы воспринимаете художественную речь: YANG — это имя для вождя
• Спецификация gNMI в его же репозитории
• Совершенно чудесный и обязательный к употреблению сайт от Аристы с описанием и примерами разных интерфейсов и инструментов: Open Management
• RESTCONF Tutorial — Everything you need to know about RESTCONF in 2020
• Серия статей про RESTCONF, но рекомендую я её из-за того, что там хорошо разобраны примеры с YANG-моделями: RESTCONF, NETCONF and YANG
• Достаточно обстоятельный разбор телеметрии поверх gNMI: Три года Телеметрии в IOS XR
• Документация по gRPC
• Python Microservices With gRPC
• Блог Романа Додина в общем. И в частности:
  • gNMIc
  • Пример взаимодействия с Arista через gNMI
• Блог Антона Карнелюка в общем. И в частности:
  • OpenConfig. Part 1. How open is OpenConfig
  • Серия Automation
  • Pygnmi блог-пост и репо.

  Но на сайте поехала вёрстка — до чего-то приходится докапываться самому.

• Блог Михаила Кашина в общем. И в частности:
  • Getting Started With NETCONF and YANG on Cisco IOS XE
• Репозиторий с PyangBind, позволяющим генерировать классы Python из YANG-моделей
• Для любителей изучать Питон по Луцу: NETCONF XML Management Protocol Developer Guide
• gRPC Network Operation Interface
• Сложный, но полезный джуниперовский документ: Understanding OpenConfig and gRPC on Junos Telemetry Interface. Я не читал 😉
• Про кишки YANG для новчиков

Благодарности

• Роману Додину за дельные комментарии как по теоретической, так и по практической частям. А так же за полезный блог и инструменты. GitHub.
• Кириллу Плетнёву за наведение порядка с NETCONF и YANG — язык, модели, спецификации, форматы данных. И за уместные и остроумные замечания по языкам и библиотекам. GitHub, fb.
• Александру Лимонову за несколько идеологических замечаний и исправлений фактических ошибок.