Do nada ao data center com VXLAN / EVPN ou como cozinhar Cumulus Linux. Parte 1

Nos últimos seis meses, conseguimos trabalhar em um grande e interessante projeto, que incluiu de tudo: desde a instalação de equipamentos até a criação de um único domínio VXLAN / EVPN em 4 data centers. Porque Eu tinha muita experiência e muitos solavancos no processo, decidi que escrever alguns artigos sobre esse assunto seria a melhor solução. Decidi tornar a primeira parte mais geral e introdutória. O projeto de destino da fábrica será revelado na próxima seção.







Apresentando Cumulus Linux. Instalação de hardware e configuração inicial



A introdução ao início do trabalho foi a seguinte:



  1. Equipamento comprado
  2. Racks alugados
  3. 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




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:~$




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.




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




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



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



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.



All Articles