
Apresentando Cumulus Linux. Instalação de hardware e configuração inicial
A introdução ao início do trabalho foi a seguinte:
- Equipamento comprado
- Racks alugados
- Linhas para data centers antigos colocadas
A primeira peça de hardware que precisava ser entregue foi 4 x Mellanox SN2410 com Cumulus Linux pré-instalado. No início ainda não havia o entendimento de como tudo ficaria (só se desenvolverá na fase de implementação de VXLAN / EVPN), portanto, decidimos criá-los como switches L3 simples com CLAG (Analógico de MLAG de Cumulus). Anteriormente, nem eu nem meus colegas tínhamos muita experiência com Cumulus, então tudo era até certo ponto novo, então quase isso.
Sem licença - sem portas
Por padrão, quando você liga o dispositivo, apenas 2 portas estão disponíveis para você - console e eth0 (também conhecida como porta de gerenciamento). Para desbloquear as portas 25G / 100G, você precisa adicionar uma licença. E imediatamente fica claro que o Linux em nome do software não é à toa, já que após instalar a licença, você precisa reiniciar o daemon switchd através de “systemctl restart switchd.service” (na verdade, a falta de uma licença apenas impede que este daemon seja iniciado).
A próxima coisa que fará você se lembrar imediatamente que este ainda é Linux, será atualizar o dispositivo usando apt-get upgrade, como em um Ubuntu normal, mas nem sempre é possível atualizar desta forma. Ao alternar entre as versões, por exemplo, de 3.1.1 para 4.1.1, você precisa instalar uma nova imagem, o que envolve redefinir as configurações para o padrão. Mas ele salva que o DHCP está ativado na interface de gerenciamento na configuração padrão, o que permite que você retorne o controle.
Licença de instalação
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
Sistema de compromisso
Como uma pessoa que trabalhou muito com a Juniper, para mim coisas como rollbacks, commit confirm, etc. não eram novos, mas conseguiram pisar em alguns ancinhos.
A primeira coisa que encontrei foi a numeração de rollback do cumulus, devido ao hábito de rollback 1 == a última configuração de trabalho. Estou dirigindo este comando com grande confiança para reverter as alterações mais recentes. Mas qual foi a minha surpresa quando o pedaço de hardware simplesmente desapareceu no controle, e por algum tempo eu não entendi o que aconteceu. Então, depois de ler o dock do cumulus, ficou claro o que tinha acontecido: conduzindo o comando "net rollback 1" em vez de reverter para a última configuração, revertei para a configuração do FIRST dispositivo. (E novamente, o DHCP salvo do fiasco na configuração padrão)
comprometer história
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:~$
A segunda coisa que tive de enfrentar foi o algoritmo de confirmação de commit: ao contrário do usual “commit confirm 10”, em que em 10 minutos você precisa escrever “commit” novamente, Cumulus tinha sua própria visão desse recurso. Sua “confirmação de confirmação” é simplesmente pressionar Enter após inserir um comando, o que pode pregar uma piada cruel em você se a conectividade não for perdida imediatamente após a confirmação.
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.
Primeira topologia
A próxima etapa foi trabalhar a lógica das chaves entre si, nesta etapa o hardware foi apenas instalado e testado, não havia nenhum esquema de destino ainda. Mas uma das condições era que os servidores conectados a pares MLAG diferentes deveriam estar no mesmo domínio L2. Eu não queria fazer um dos pares simples L2 e, portanto, foi decidido aumentar a conectividade L3 sobre SVI, OSPF foi escolhido para o roteamento, uma vez que ele já foi usado em data centers mais antigos, tornando mais fácil conectar a infraestrutura na próxima etapa.

Este diagrama mostra o diagrama físico + a divisão dos dispositivos em pares, todos os links do diagrama funcionam no modo Tronco.

Como mencionado, toda a conectividade L3 é feita através de SVI, portanto, apenas 2 dos 4 dispositivos possuem um endereço IP em cada Vlan, o que permite fazer uma espécie de pacote L3 p2p.
Comandos básicos para os interessados
Bond (canal de porta) + 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
Modo tronco / porta de acesso
# 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 + Estático
#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
Conclusão
Espero que alguém ache este artigo interessante. Eu gostaria de ver o feedback: o que adicionar e o que é completamente desnecessário. No próximo artigo, já passaremos para o mais interessante - o design da rede de destino e a configuração de VXLAN / EVPN. E no futuro, um artigo sobre automação de VXLAN / EVPN usando Python é possível.