IaC-аем лабы

Roman

Итак, IaC это хорошо и абстрактненько.

Чем может быть полезен IaC нашему брату сетевику?

Ну во-первых, ВНЕЗАПНО, можно автоматизировать настройки сетевого оборудования через какой-нибудь сраный Ansible. Про Ansible и как им настраивать сетевое железо мильён статей, про это писать нет смысла.

Есть ещё моднейший Terraform - https://www.terraform.io/

Тераформ штука декларативная и работает с тем у кого есть API. Если ваш каталист 2950 имеет API - пожалуйста, пробуйте В целом, для циски можно конфигурить такие штуки:

Для остальных вендоров гуглите "Vendor-name Terraform provider"

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

Что есть из лаб? Сейчас, наверное, де-факто стандартом у всякого рода сетевиков для лабания является EVE-NG. EVE-NG - это куча забриджованных между собой qemu-виртуальных машин со всякими свистелками и перделками в виде веб-морды и прочими ваершарками.

То, что есть веб-морда - это хорошо, потому что красиво. Но плохо, потому что надо НАКЛИКИВАТЬ себе виртуалочки и связи между ними.

Я, увы, не нашёл способо описать желаемую топологию в виде файла - скормить его EVE и получить готовую лабу, хотя чую, что такой способ должен быть. В общем, кажется, что "нативного" способа управлять лабами в EVE с помощью IaC подхода нет.

А пока я писал предыдущий абзац, я вспомнил, что в EVE можно экспортировать\импортировать лабы, и скорее всего они как-то всё-таки должны описывать файлами. Пошёл - выгрузил, открыл, получил xml-ку.

В общем, чтобы сделать вот такую топологию:

Мне нужно скрафтить вот такой XML-ничек:

Наверное, накалякать какую-то обёртку, на выходе которой будут готовые xml-ники для лаб не сложно.

Но я, пошёл другим идиотским путём. EVE-NG - это веб, и у него есть API. Можно всякими POST-ами и PUT-ами нарисовать себе лабу.

ВНИМАНИЕ, дальнейшие строки могут вызвать кровь из глаз и на них не рекомендуется смотреть настоящим ТРУ ПОГРАМИСТАМ или НЕТОПСам:

Исходники можно глянуть тут (если это вообще, кому-то может быть интересно) - https://github.com/friedstump/Small_Net_Tools/blob/master/Iac/EVE-NG-Simple_topo.py

Комментировать смысла нет. Краткий итог - с помощью питона и какой-то там матери можно создавать лабы в EVE-NG. И для достаточно простой топологии нужно кодом описывать все встречаемые сущности - ноды, бриджы,коннекты этих нод к этим бриджам. При этом для каждой ноды (читай виртуалки) надо подбирать ПРАВИЛЬНЫЕ параметры запуска, посмотрите на этот XML-кусок для запуска одной Аристы:

<node id="1" name="Arista_1" type="qemu" template="veos" image="veos-4.29.2F" console="telnet" cpu="1" cpulimit="0" ram="2048" ethernet="9" uuid="3017f4ad-4d66-49c1-b430-ddde7d59cc17" firstmac="50:02:00:01:00:00" qemu_options="-machine type=pc,accel=kvm -serial mon:stdio -nographic -display none -no-user-config -rtc base=utc -boot order=d" qemu_version="4.1.0" qemu_arch="x86_64" delay="0" sat="0" icon="AristaSW.png" config="0" left="369" top="816">

...пойди ещё пойми что это такое и как правильно.

Вот бы кто-нибудь сделал так, чтобы можно было просто описать лабу словами - "Запусти-ка мне, чудо-машина, две аристы, а между ними Cumulus зафигачь. Первую аристу подключи к кумулусу и вторую тоже!", а потом просто кнопку нажать и всё готово, вот здорово бы было!

В общем, пацаны уже всё сделали давно.

Встречайте, containerlab!

Цитата от основного контрибутора проекта, Романа Додина:

появился в 2019 году в сетевом подразделении nokia

мы тогда выпустили первый релиз сетевой операционки SR Linux и виртуальный образ у нее был только в виде контейнерного имаджа.

Поэтому надо было сделать утилиту, которая бы строила сетевые топологии с SR Linux контейнерами для внутренних демо, обучения и тд.

В скором времени мы добавили пару других сетевых ОС, чтобы симулировать миграции с одного вендора на SR Linux; так началась мультивендорная часть контейнерлаба. Еще чуть позже добавили поддержку виртуальных машин, путем форка/интеграции vrnetlab.

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

Так все и началось.

И это действительно полезно другим (вам и мне).

Я выдам БАЗУ по продукту. За подробностями всегда можно сходить на сайт проекта - https://containerlab.dev/

Итак, по факту - это оркестратор докеров и связей между ними, поэтому вначале на хост надо поставить Docker. После запуска докера ОБЯЗАТЕЛЬНО надо, что бы он поздоровался с миром:

Теперь у вас в имаджах ровно один образ:

После этого выполнить установку контейнерлаба одной командой:

sudo bash -c "$(curl -sL https://get.containerlab.dev)"

Успех:

К великому сожалению, containerlab не понимает (пока!) русский язык, и предыдущее желание приходится с помощью гугл-переводчика переводить на yaml, то бишь получаем что-то такое:

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

Про топологии читаем тут - https://containerlab.dev/manual/topo-def-file/

Про Nod-ы тут - https://containerlab.dev/manual/nodes/

Про kinds-ы тут - https://containerlab.dev/manual/kinds/

Ок. Сделали yml. Обозвали его что-то.clab.yml и стартуем лабу командой "sudo containerlab deploy" из каталого где создана лаба.

Так, в общем оно распарсило файл, создало management сеть, которую забриджует, а на бридж повесит какой-нить IP на хосте - ну что бы вы могли на докеры ходить.Потом оно попыталось запустить докер с аристой, не шмогла, попыталась скачать докер с докер-хаба - а там хуй. На докер хабе нет контейнеров с Аристой. Они только у самой Аристы есть, оказывается. В общем, врубайте VPN, регайтесь на сайте Аристы и скачивайте что нибудь типа "cEOS64-lab-4.28.10.1M.tar" - смотрите, что бы в файле было именно что lab - это важно )

Дальше импортируйте сей докер в ваш локальный репозиторий. Теперь у вас есть образ Аристы!

Я поставил кастомный тег, поэтому надо немного изменить на yaml:

Пробуем ещё:

В этот раз он понял что теперь у него нету образа для кумулуса, пошёл в Интернеты и забрал его оттуда - импортнул (попутно забрав ещё несколько родительских образов)

Потом пошла какая-то непонятная для меня дикая дичь, в итоге кумулус похоже, не запустился, зато Аристы - ок. Можно даже на них по ssh зайти теперь:

Но нам надо разобраться с кумулусом. Пора почитать документацию - https://containerlab.dev/manual/kinds/cvx/

В общем, там написано что кумулус может запускаться в двух режимах - чисто как докер, а также как какой-то неведомый мне "Firecracker micro-VMs", причём второй вариант по дефолту. Нет времени разбираться почему у меня не работает этот петард, давайте попробуем запустить просто докер, добавлям к нашей ноде доп. параметр:

Пробуем, предварительно уничтожив предыдущую лабу командой "sudo containerlab destroy":

В этот раз мне повезло больше и все три ноды стартанули. После запуска кумулуса он не сразу доступен по ssh - линукс там загружается, все дела, подождите немножк. Посмотреть статус загрузки можно посмотрев, что же там наш докер шлёт "в консоль" командой " sudo docker logs -f clab-Laba1-Cumulus"

В общем, подождали, загрузились, идём управлять!:

Если вы забыли что у вас с чем соединено, или не можете спарсить в голове вот эту вот строку:

всегда можно глянуть на графическое изображение связей между нодами - запускам командочку и идём на свой хост через веб-сервис:

Ок. Вроде лаба собрана, давайте хоть проверим, что нибудь "сетевое", например запустим bgp между девайсами и заанонсируем лупбеки арист друг другу:

настраиваем P2P интерфейсы
запускаем демона bgpd на кумулусе
настраиваем bgp (на кумулусе это делается внутри FRR-а, чтобы настроить его, достаточно набрать vtysh и вы провалитесь в циско-лайк консоль:

Итоговые конфиги, сделанные своими руками:

На FRR-е bgpd по умолчанию выключен - его надо выключить, немножк поправив конфигурационный файл ну и сервис рестартануть:

Потом фигачим конфиг:

Это всё что он вывел после show run, хотя через тот же vtysh я настроил интерфейсы

Теперь на cumulus-е есть две bgp сессии, по которым прилетают лупбеки:

Ну и реанонсятся на Аристы и Аристы могут пингать друг друга:

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

Увы, не все вендора предоставляют свои NOS в виде докер-образов. Например, всеми любимый Cisco Nexus - это по прежнему qemu-машина, а хотелось бы и её так ловко одной строчкой запускать...

Ну ребята из containerlab нашли выход - и давай запихивать виртуальные машины прямо в докер.

Например на сайте про это написано - https://containerlab.dev/manual/kinds/vr-n9kv/ - это нексус который запускается как докер с помощью проекта vrnetlab - https://containerlab.dev/manual/vrnetlab/ . Вы почитайте-почитайте, там не сложно. Подкладываете qemu образ - пару магических движений руками, и виртуалка запустится внутри докера, пройдя даже стандартные POAP процедуры - скрипт ответит за вас на все вопросы. Сейчас не хочу про это писать, но у меня получилось.

По итогу - можно с помощью YML файла запускать лабы. Ништяк. Чего ещё можно хотеть? Можно хотеть не прописывать ручками все эти IP адреса и конфигурации разных протоколов. Больше абстракций хочется вот чего.

Где там картинка с Дашей-разработчицей...

Вот бы теперь бездушной машине давать такие команды:

"Запусти-ка мне, чудо-машина, две аристы, а между ними Cumulus зафигачь. Первую аристу подключи к кумулусу и вторую тоже! Да, адреса ещё настрой сразу за меня. И OSFP настройка. А то лень"

Иван услушал наши мольбы и улыбается нам:

Встречайте - netlab tools!

Как пишет сам Иван, он устал крафтить конфигурационные файлы для своих лаб на Vagrant-е и решил сделать волшебство. И у него получилось.

С помощью netlab можно опять-таки с помощью yaml-ов описывать топологию. И после запуска лабы - автоматом прописываются IP-адреса, автоматом настраиваются необходимые нам протоколы. В целом и делать ничего не надо - только show командами смотреть что получилось.

Что приятно провайдером может быть не только docker (который кстати работает за счёт описанного ранее containerlab-а), но и ливбир, а то и VirtualBox.

А ещё, а ещё можно прямо железными свичами управлять - если смелые можно сразу прод настраивать!

Итак идём на сайт https://netlab.tools/ и попробуем всё установить.

Устанавливается всё через обычный питоновский PIP:

Упс, сам PIP то и не установлен. Выкачиваем 280 мегабайт питоновского барахла с помощью "apt install python3-pip" , и пробуем ещё раз:

Даём команду "netlab test clab" где последний аргумент - провайдер, которым будем пользоваться, в нашем случае clab=containerlab

После этого с помощью clab-а запускается тестовый стенд и происходит попытка накатить на него базовый конфиг:

Попытка не увенчалась успехом из-за того что раскатка конфигурации должна происходить ansibl-ом , а его у нас нет. Это конечно же легко исправляется - можно поставить ручками, а можно с помощь этого самого нетлаба - просто пишем "netlab install ansible" и ждём )

Дальше запускаем тест ещё раз - у меня он прошёл успешно, если у вас нет - это ваши проблемы, разбирайтесь, пожалуйста.

Можно программировать сеть на ямле теперь.

Всё опять начинается с топологии. Все моментики про топологию описаны тут - https://netlab.tools/topology-reference/

А поддерживаемые платформы тут - https://netlab.tools/platforms/

Давайте опять попробовать перевести наш запрос на язык понятный этому нетлабу. Получается вот так:

Мы, как бэ говорим нетлабу:

используй clab как провайдер
если кто-то попросит у тебя Аристу - вот такой образ используй (у него где-то внутри в дефолтах стоит другой образ, я пока не нашёл как менять, поэтому указываю ручками)
а ещё нам нужны три ноды, и пусть это будут две аристы (r1 и r3) и один кумулус (r2)
соедени их вот таким образом, сделай stub интерфейсы на r1 и r3
и osfp нам запили сразу!

Дальше пихаем это всё в файл "topology.yml" и из директории даём команду "netlab up":

Сначал отрабатывает уже знакомый нам containerlab И создаёт окружение:

Следующим этапом происходит раскатка конфигурации (!) ансиблом. Там достаточно длинная простыня текста, поэтому покажу только итог:

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

Ну а дальше коннектимся в cumulus, который посередине и смотрим чё там у нас:

Вау, а тут нас ждёт сразу готовый конфиг, запущенный osfp и даже прилетевшие по OSFP маршруты.

Со стороны одной из Арист мы видем такой конфиг (без рук сделанный):

В общем. По дефолту кроме добавления самих нод и линков между ними netlab пропишет вам адреса на интерфейсы из своего ipam-модуля. Чтобы заработал ospf я добавил дополнительный модуль. Вот это:

Список модулей, которые поддерживаются сейчас описан тут - https://netlab.tools/module-reference/ от VLAN-ов до EVPN\VXLAN-а...

Божественно, Иван молодец.

А может быть можно ещё больше абстракций?

Конечно, говорит, Иван, и запиливает "плагины" - это некий способо крутить-вертеть модель данных как вы захотите. И самый прикольный пример это плагин "fabric" - https://netlab.tools/plugins/fabric/

Вы просто говорите сколько вам нужно спайнов и лифоф и вуаля, больше ничего не надо всё работает!

Пять строчек ямла - и у вас целая клос-сеть с настроеными IP-адресами.

А если ещё и модули добавить...мммм...

Давайте я попробую собрать EVPN\VXLAN фабрику с лифами на аристах, спайнами на кумулусах, с андерлеем в виде osfp-а, и evpn-ом (ibgp с роут-рефлекторами). А потом мы подключим туда хосты и свяжим их по L2 через IP-фабрику.

И всё это несколькими строчками в ямле? Ну да. Собственно вот он Yaml-то: