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

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

На самом деле некая неявная привязка есть - это пути, они могли бы отличаться для Аристы и Хуавэя. Но внимание на слово «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.

Так почему мы делаем это сотней разных способов?

Настройка интерфейса:

Juniper:

configure
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30
commit and-quit

Nokia:

router
interface "test"
address 10.0.0.1
port 1/1/1
no shutdown
exit

Cisco:

conf t
interface gigabitethernet1
ip address 10.0.0.1 255.255.255.252
no shut
exit

Настройка BGP:

Juniper:

configure
set routing-options router-id 10.0.0.1
set routing-options autonomous-system 65000
set protocols bgp group test type internal
set protocols bgp group test peer-as 65000
set protocols bgp group test neighbor 10.0.0.2 redistribute-connected
set policy-options policy-statement redistribute-connected from protocol direct
set policy-options policy-statement redistribute-connected then accept
commit and-quit

Nokia:

router
autonomous-system 6500
router-id 10.0.0.1
bgp group "ibgp"
 type internal
 neighbor 10.10.10.2
exit

Cisco:

conf t
router bgp 65000
 bgp router-id 10.0.0.1
 neighbor 10.0.0.2 remote-as 65000
 redistribute connected
exit

Сложность ведь не в транспорте и не в интерфейсе, а в модели данных. Сделать у каждого вендора 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?