В последние полгода удалось поработать над большим и интересным проектом, в котором было все: от монтажа оборудования до создания единого VXLAN/EVPN домена в 4-х ЦОД. Т.к. было получено много опыта и набито много шишек в процессе, решил что написать несколько статей на эту тему будет наилучшим решением. Первую часть я решил сделать более общей и вводной. Целевой дизайн фабрики будет раскрыт в следующей части.

Знакомство с Cumulus Linux. Установка оборудования и первоначальная настройка

Вводные к началу работ были следующие:

1. Закуплено оборудование
2. Арендованы стойки
3. Проложены линии к старым ЦОД

Первой порцией оборудования, которое необходимо было поставить, стали 4 х Mellanox SN2410 с предустановленным на них Cumulus Linux. На первых порах еще не было понимания как все должно будет выглядеть (сложится оно только к этапу внедрения VXLAN/EVPN), следовательно, мы решили поднять их как простые L3 коммутаторы с CLAG (Аналог MLAG от Cumulus). Ранее опыта работы с Cumulus ни у меня, ни у коллег сильно не было, так что все в какой-то степени было в новинку, дальше как раз про это.

Нет лицензии – нет портов

По умолчанию при включении устройства вам доступны только 2 порта — console и eth0(он же Management port). Чтобы разблокировать 25G/100G порты нужно добавить лицензию. И сразу становится понятно, что Linux в названии ПО не просто так, т.к. после установки лицензии надо перезагрузить демона switchd, через “systemctl restart switchd.service” (по факту отсутствие лицензии как раз и не дает запуститься данному демону).

Следующее, что сразу заставит вас вспомнить что это все-таки Linux, будет обновление устройства используя apt-get upgrade, как в обычном Ubuntu, но обновиться так можно не всегда. При переходе между релизами, например, с 3.1.1 на 4.1.1, нужно устанавливать новый образ, что влечет за собой сброс конфиги в дефолт. Но спасает то, что в конфигурации по умолчанию на Management интерфейсе включен DHCP, что позволяет вернуть управление.

Система commit’ов

Как человек, много работавший с Juniper, для меня такие вещи как rollback’и, commit confirm и т.д. были не в новинку, но наступить на пару граблей удалось.

Первое, на что я напоролся, была нумерация rollback у cumulus, в силу привычки rollback 1 == последняя рабочая конфигурация. Я с огромной уверенностью вбиваю данную команду, чтобы откатить последние изменения. Но каково было мое удивление, когда железка просто пропала по управлению, и какое-то время я не понимал, что произошло. Потом, прочитав доку от cumulus, стало понятно, что случилось: вбив команду “net rollback 1” вместо отката на последнюю конфигурацию, я откатился на ПЕРВУЮ конфигурацию устройства.(И опять же, от фиаско спас DHCP в дефолтной конфигурации)


Второе, с чем пришлось столкнуться, был алгоритм работы commit confirm: в отличие от привычного нам “commit confirm 10”, где в течении 10 минут нужно еще раз прописать “commit”, у Cumulus было свое виденье данной фичи. Ваше подтверждение “commit confirm” это простое нажатие Enter после ввода команды, что может сыграть с вами злую шутку, если связность потеряется не сразу после commit.

Первая топология

Следующим этапом была проработка логики работы коммутаторов между собой, на данном этапе железо только ставилось и тестировалось, ни о каких целевых схемах речи еще не шло. Но одним из условий было, что сервера подключенные к разным MLAG парам должны быть в одном L2 домене. Делать одну из пар простым L2 не хотелось, в связи с чем было решено поднять L3 связность поверх SVI, для маршрутизации был выбран OSPF, т.к. он уже использовался в старых ЦОД, что упрощало соединение инфраструктуры на следующем этапе.



На данной схеме отображена схема физики + разделение устройств по парам, все линки на схеме работают в режиме Trunk.



Как и говорилось, вся L3 связность сделана через SVI, следовательно, IP адрес в каждом Vlan есть только у 2 устройств из 4, что позволяет сделать своего рода L3 p2p связку.

Основные команды для заинтересованных

Заключение

Надеюсь, кому-нибудь данная статья покажется интересной. Хотелось бы увидеть feedback: что добавить, а что совсем лишнее. В следующей статье уже перейдем к самому интересному — к дизайну целевой сети и настройке VXLAN/EVPN. И в будущем возможна статья по автоматизации VXLAN/EVPN средствами Python.