На самом деле некая неявная привязка есть - это пути, они могли бы отличаться для Аристы и Хуавэя. Но внимание на слово "openconfig" в этих путях. Что это? Что за Открытый конфиг?
Даже просто для того, чтобы настроить 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 подвезли такую функцию.
system->login
, чтобы настроить нового пользователя, а формат команды будет set <USERNAME> <OTHER PARAMETERS>
.А настройка IP-адреса управления при этом будет происходить в контексте
interface -> em0 -> unit 0 -> family inet
. И так будет всегда. Во всяком случае на этой железке и этой версии софта.То есть модель данных - это контракт между пользователем и операционной системой - как она интерпретирует переданные команды в зависимости от контекста.
Это верно для CLI, SNMP, NETCONF, gNMI и даже прямых вызовов чипового SDK.
И вендор может менять эту модель по своему усмотрению от версии к версии. А мы как люди к этому адаптируем свою внутреннюю модель, приспосабливаемся - по законам эволюции.
Так было всегда, но это поменялось с приходом автоматизации. Вендоры, как будто бы думали, что рост сетей можно поддерживать постоянным докидыванием людей на их настройку. Но людям это не нравилось, они начали писать инструменты автоматизации на perl'ах, php, python'ах с expect'ами, попытками отловить все возможные ответы CLI, правильно на них среагировать. Но количество скорби в этом мире только множилось. Все рано или поздно приходили к пониманию, что долго притворяться робот человеком не может.
Автор утилиты/библиотеки, опираясь на этот контракт, пишет код, а вендор обязуется принять данные, которые ему прислали. Если вы присылаете соответствующие контракту данные, а вендор говорит, что вы ерунду прислали, вы идёте в суд (в TAC).
Но необходимость приводить это всё к каким-то явным схемам становилась всё очевиднее с каждым днём. К этому же подталкивал и расцвет NMS, берущих на вооружение NETCONF.
И так появились первые модели данных - NATIVE. У каждого вендора своя, но уже модель, и уже открытая. Вендоры с достаточно высокой социальной ответственностью выкладывают свои модели в публичный репозиторий.
А при желании модель читать программно и руками даже ничего не делать.
Инженерам нужно было чуть меньше думать об интерфейсах и форматах сообщений, но с глубоким вниманием подходить к содержимому сообщений всё ещё приходилось, оказывая разные знаки почтения разным вендорам.
Так почему мы делаем это сотней разных способов?
Настройка интерфейса:
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 -модель очень медленно развивается, у неё низкое покрытие, а архитектура - так себе.
С IETF-модели рекомендуют начинать, потому что она якобы проще, а уже потом переходить на OpenConfig, но как по мне - это напрасная трата времени.
Она мертворождённая и никому особо не нужна. Хотя вендоры поддерживают.
Заказчиков и пользователей беспокоила обрезанность модели и инертность IETF.
Но один в поле не воин - тысячи разрозненных автоматизаторов по всему миру не могли ничего с этим сделать. А вот большие компании могли.
Когда надо настроить тысячу свитчей, а каждый месяц запускать новый датацентр, когда на сети 5 разных поколений дизайна, а катить изменения нужно дважды в день, начинаешь несколько иначе смотреть на все этим ваши сиэлаи и вендор-специфичные эксэмали.
Так гугл придумал OpenConfig. Он не стал размениваться на IETF-модели и торги со стариканами из института.
Возможно, впервые за шестидесятилетнюю историю телекоммуникаций у нас появился шанс изобрести свой 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)
Полезным было бы взглянуть на структуру этой модели. Но это мы сделаем в следующей главе про YANG.
OpenConfig сегодня даёт возможность настройки базовых сервисов. Безусловно речь не идёт про вещи, завязанные на аппаратные особенности: QoS, управление буферами и ресурсами чипа, сплиты портов, работа с трансиверами. И в каком-то хоть сколько-то обозримом будущем этого ждать не стоит.
Хуже того, на сегодняшний день многие вендоры, ввязавшиеся в поддержку OC, не реализуют все 100%, а лишь часть.
Но BGP с OSPF настроить точно можно.
Что делать в этом случае?
Один из них - брать OC и видоизменять его с помощью добавления или убирания каких-либо его частей.
Когда вендор хочет расширить покрытие модели - он делает augmentation, встраивая его в нужное место.
Если он хочет поменять какое-то поведение или удалить функциональность - он описывает deviation к базовой модели.
Этот способ, конечно, не покрывает все потребности.
Другой - использовать вендорские Native модели, покрытие которых намного больше.
Абсолютно нормально совмещать OC и Native - главное, не настраивать одно и то же с помощью разных моделей. В целом рекомендуют (даже сами вендоры), использовать OC там, где это возможно, а где нет - прибегать к native.
Источник: доклад на Cisco Live
Но в качестве транспорта для OC может быть как gNMI, так и NETCONF и RESTCONF - это не принципиально. В то же время, для gNMI OpenConfig в частности и YANG вообще не единственные возможные модели и языки.
Так что же это за мифический YANG?