В последние полгода удалось поработать над большим и интересным проектом, в котором было все: от монтажа оборудования до создания единого VXLAN/EVPN домена в 4-х ЦОД. Т.к. было получено много опыта и набито много шишек в процессе, решил что написать несколько статей на эту тему будет наилучшим решением. Первую часть я решил сделать более общей и вводной. Целевой дизайн фабрики будет раскрыт в следующей части.
Вводные к началу работ были следующие:
Первой порцией оборудования, которое необходимо было поставить, стали 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, что позволяет вернуть управление.
Как человек, много работавший с 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.
Часть 2
Знакомство с Cumulus Linux. Установка оборудования и первоначальная настройка
Вводные к началу работ были следующие:
- Закуплено оборудование
- Арендованы стойки
- Проложены линии к старым ЦОД
Первой порцией оборудования, которое необходимо было поставить, стали 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, что позволяет вернуть управление.
Установка лицензии
cumulus@Switch1:~$ sudo cl-license -i
balagan@telecom.ru|123456789qwerty
^+d
cumulus@Switch1:~$ sudo systemctl restart switchd.service
P.S. Дефолтная конфигурация eth0(mgmt) интерфейса:
cumulus@Switch1:~$ net show configuration commands | grep eth
net add interface eth0 ip address dhcp
net add interface eth0 vrf mgmt
balagan@telecom.ru|123456789qwerty
^+d
cumulus@Switch1:~$ sudo systemctl restart switchd.service
P.S. Дефолтная конфигурация eth0(mgmt) интерфейса:
cumulus@Switch1:~$ net show configuration commands | grep eth
net add interface eth0 ip address dhcp
net add interface eth0 vrf mgmt
Система commit’ов
Как человек, много работавший с Juniper, для меня такие вещи как rollback’и, commit confirm и т.д. были не в новинку, но наступить на пару граблей удалось.
Первое, на что я напоролся, была нумерация rollback у cumulus, в силу привычки rollback 1 == последняя рабочая конфигурация. Я с огромной уверенностью вбиваю данную команду, чтобы откатить последние изменения. Но каково было мое удивление, когда железка просто пропала по управлению, и какое-то время я не понимал, что произошло. Потом, прочитав доку от cumulus, стало понятно, что случилось: вбив команду “net rollback 1” вместо отката на последнюю конфигурацию, я откатился на ПЕРВУЮ конфигурацию устройства.(И опять же, от фиаско спас DHCP в дефолтной конфигурации)
commit history
cumulus@Switch1:mgmt:~$ net show commit history
# Date Description
— — — 2 2020-06-30 13:08:02 nclu «net commit» (user cumulus)
208 2020-10-17 00:42:11 nclu «net commit» (user cumulus)
210 2020-10-17 01:13:45 nclu «net commit» (user cumulus)
212 2020-10-17 01:16:35 nclu «net commit» (user cumulus)
214 2020-10-17 01:17:24 nclu «net commit» (user cumulus)
216 2020-10-17 01:24:44 nclu «net commit» (user cumulus)
218 2020-10-17 12:12:05 nclu «net commit» (user cumulus)
cumulus@Switch1:mgmt:~$
# Date Description
— — — 2 2020-06-30 13:08:02 nclu «net commit» (user cumulus)
208 2020-10-17 00:42:11 nclu «net commit» (user cumulus)
210 2020-10-17 01:13:45 nclu «net commit» (user cumulus)
212 2020-10-17 01:16:35 nclu «net commit» (user cumulus)
214 2020-10-17 01:17:24 nclu «net commit» (user cumulus)
216 2020-10-17 01:24:44 nclu «net commit» (user cumulus)
218 2020-10-17 12:12:05 nclu «net commit» (user cumulus)
cumulus@Switch1:mgmt:~$
Второе, с чем пришлось столкнуться, был алгоритм работы commit confirm: в отличие от привычного нам “commit confirm 10”, где в течении 10 минут нужно еще раз прописать “commit”, у Cumulus было свое виденье данной фичи. Ваше подтверждение “commit confirm” это простое нажатие Enter после ввода команды, что может сыграть с вами злую шутку, если связность потеряется не сразу после commit.
net commit confirm 10
cumulus@Switch1:mgmt:~$ net commit confirm 10
— /etc/network/interfaces 2020-10-17 12:12:08.603955710 +0300
+++ /run/nclu/ifupdown2/interfaces.tmp 2020-10-29 19:02:33.296628366 +0300
@@ -204,20 +204,21 @@
auto swp49
iface swp49
+ alias Test
link-autoneg on
net add/del commands since the last «net commit»
================================================
User Timestamp Command
— — — cumulus 2020-10-29 19:02:01.649905 net add interface swp49 alias Test
Press ENTER to confirm connectivity.
— /etc/network/interfaces 2020-10-17 12:12:08.603955710 +0300
+++ /run/nclu/ifupdown2/interfaces.tmp 2020-10-29 19:02:33.296628366 +0300
@@ -204,20 +204,21 @@
auto swp49
iface swp49
+ alias Test
link-autoneg on
net add/del commands since the last «net commit»
================================================
User Timestamp Command
— — — cumulus 2020-10-29 19:02:01.649905 net add interface swp49 alias Test
Press ENTER to confirm connectivity.
Первая топология
Следующим этапом была проработка логики работы коммутаторов между собой, на данном этапе железо только ставилось и тестировалось, ни о каких целевых схемах речи еще не шло. Но одним из условий было, что сервера подключенные к разным MLAG парам должны быть в одном L2 домене. Делать одну из пар простым L2 не хотелось, в связи с чем было решено поднять L3 связность поверх SVI, для маршрутизации был выбран OSPF, т.к. он уже использовался в старых ЦОД, что упрощало соединение инфраструктуры на следующем этапе.
На данной схеме отображена схема физики + разделение устройств по парам, все линки на схеме работают в режиме Trunk.
Как и говорилось, вся L3 связность сделана через SVI, следовательно, IP адрес в каждом Vlan есть только у 2 устройств из 4, что позволяет сделать своего рода L3 p2p связку.
Основные команды для заинтересованных
Bond(Port-channel)+CLAG(MLAG)
#Используем vrf mgmt согласно всем best-practice
net add interface peerlink.4094 clag backup-ip Х.Х.Х.Х vrf mgmt
#Чем меньше адресов тем лучше(можно вместо linklocal использовать IP адреса)
net add interface peerlink.4094 clag peer-ip linklocal
#Берем из пула указанного в документации 44:38:39:ff:00:00-44:38:39:ff:ff:ff
net add interface peerlink.4094 clag sys-mac Х.X.X.X.X
#Cоздание Bond#Добавляем интерфейсы которые нужно агрегировать
net add bond bond-to-sc bond slaves swp1,swp2
#Выбираем LACP
net add bond bond-to-sc bond mode 802.3ad
#Подаем VLAN в Bond
net add bond bond-to-sc bridge vids 42-43
#Присваиваем уникальный ID
net add bond bond-to-sc clag id 12
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces
Проверка работоспособности
cumulus@Switch1:mgmt:~$ net show clag
The peer is alive
Our Priority, ID, and Role: 32768 1c:34:da:a5:6a:10 secondary
Peer Priority, ID, and Role: 100 b8:59:9f:70:0e:50 primary
Peer Interface and IP: peerlink.4094 fe80::ba59:9fff:fe70:e50 (linklocal)
VxLAN Anycast IP: 10.223.250.9
Backup IP: 10.1.254.91 vrf mgmt (active)
System MAC: 44:39:39:aa:40:97
net add interface peerlink.4094 clag backup-ip Х.Х.Х.Х vrf mgmt
#Чем меньше адресов тем лучше(можно вместо linklocal использовать IP адреса)
net add interface peerlink.4094 clag peer-ip linklocal
#Берем из пула указанного в документации 44:38:39:ff:00:00-44:38:39:ff:ff:ff
net add interface peerlink.4094 clag sys-mac Х.X.X.X.X
#Cоздание Bond#Добавляем интерфейсы которые нужно агрегировать
net add bond bond-to-sc bond slaves swp1,swp2
#Выбираем LACP
net add bond bond-to-sc bond mode 802.3ad
#Подаем VLAN в Bond
net add bond bond-to-sc bridge vids 42-43
#Присваиваем уникальный ID
net add bond bond-to-sc clag id 12
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces
Проверка работоспособности
cumulus@Switch1:mgmt:~$ net show clag
The peer is alive
Our Priority, ID, and Role: 32768 1c:34:da:a5:6a:10 secondary
Peer Priority, ID, and Role: 100 b8:59:9f:70:0e:50 primary
Peer Interface and IP: peerlink.4094 fe80::ba59:9fff:fe70:e50 (linklocal)
VxLAN Anycast IP: 10.223.250.9
Backup IP: 10.1.254.91 vrf mgmt (active)
System MAC: 44:39:39:aa:40:97
Trunk/Access port mode
#Создаем интерфейс Vlan
net add vlan 21 ip address 100.64.232.9/30
#Назначаем ID
net add vlan 21 vlan-id 21
#Подаем в L2 Bridge
net add vlan 21 vlan-raw-device bridge
P.S. На данном этапе VLAN уже будет подан на Bridge порты
#Trunk порт (все bridge vlan)
net add bridge bridge ports swp49
#Trunk порт (ограниченный пул VLAN)
net add interface swp51-52 bridge vids 510-511
#Access порт
net add interface swp1 bridge access 21
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces
net add vlan 21 ip address 100.64.232.9/30
#Назначаем ID
net add vlan 21 vlan-id 21
#Подаем в L2 Bridge
net add vlan 21 vlan-raw-device bridge
P.S. На данном этапе VLAN уже будет подан на Bridge порты
#Trunk порт (все bridge vlan)
net add bridge bridge ports swp49
#Trunk порт (ограниченный пул VLAN)
net add interface swp51-52 bridge vids 510-511
#Access порт
net add interface swp1 bridge access 21
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces
OSPF+Static
#Static route для mgmt
net add routing route 0.0.0.0/0 10.1.255.1 vrf mgmt
#OSPF с включением по принадлежности к Network
net add ospf network 0.0.0.0 area 0.0.0.0
#OSPF на определенном интерфейсе
net add interface lo ospf area 0.0.0.0
P.S. На Cumulus может быть только один Loopback интерфейс
#OSPF редистрибьюции
net add ospf redistribute connected
P.S. Данный функционал так же можно конфигурировать через vtysh(c Cisco like синтаксисом), т.к. в Cumulus используется FRR
net add routing route 0.0.0.0/0 10.1.255.1 vrf mgmt
#OSPF с включением по принадлежности к Network
net add ospf network 0.0.0.0 area 0.0.0.0
#OSPF на определенном интерфейсе
net add interface lo ospf area 0.0.0.0
P.S. На Cumulus может быть только один Loopback интерфейс
#OSPF редистрибьюции
net add ospf redistribute connected
P.S. Данный функционал так же можно конфигурировать через vtysh(c Cisco like синтаксисом), т.к. в Cumulus используется FRR
Заключение
Надеюсь, кому-нибудь данная статья покажется интересной. Хотелось бы увидеть feedback: что добавить, а что совсем лишнее. В следующей статье уже перейдем к самому интересному — к дизайну целевой сети и настройке VXLAN/EVPN. И в будущем возможна статья по автоматизации VXLAN/EVPN средствами Python.
Часть 2
