O SDSM acabou, mas a vontade incontrolável de escrever permanece.

Por muitos anos, nosso irmão sofreu com trabalhos rotineiros, cruzando os dedos antes de se comprometer e sem dormir devido a retrocessos noturnos.
Mas os tempos sombrios estão chegando ao fim.

Com este artigo começarei uma série sobre como me a automação é vista.
Ao longo do caminho entenderemos as etapas de automação, armazenamento de variáveis, formalização de design, RestAPI, NETCONF, YANG, YDK e faremos muita programação.
Me significa que a) não é uma verdade objectiva, b) não é incondicionalmente a melhor abordagem, c) a minha opinião, mesmo durante a passagem do primeiro para o último artigo, pode mudar - para ser sincero, da fase de projecto para publicação, reescrevi tudo completamente duas vezes.

Conteúdo

1. Objetivos
   1. A rede é como um único organismo
   2. Teste de configuração
   3. Versionamento
   4. Monitoramento e autocorreção de serviços

2. Fundos
   1. sistema de inventário
   2. Sistema de gerenciamento de espaço IP
   3. Sistema de descrição de serviço de rede
   4. Mecanismo de inicialização do dispositivo
   5. Modelo de configuração independente de fornecedor
   6. Interface de driver específica do fornecedor
   7. Mecanismo para entregar configuração ao dispositivo
   8. CI / CD
   9. Mecanismo de backup e busca de desvios
   10. Sistema de monitoramento

3. Conclusão

Tentarei conduzir o ADSM em um formato um pouco diferente do SDSM. Continuarão a aparecer artigos grandes, detalhados e numerados, e entre eles publicarei pequenas notas da experiência cotidiana. Vou tentar lutar contra o perfeccionismo aqui e não lamber cada um deles.

Que engraçado que na segunda vez você tenha que seguir o mesmo caminho.

No começo, eu mesmo tive que escrever artigos sobre redes devido ao fato de elas não estarem no RuNet.

Agora não consegui encontrar um documento abrangente que sistematizasse as abordagens de automação e analisasse as tecnologias acima usando exemplos práticos simples.

Posso estar errado, então forneça links para recursos úteis. Porém, isso não vai mudar minha determinação em escrever, pois o objetivo principal é aprender algo sozinho, e facilitar a vida dos outros é um bônus agradável que acaricia o gene para compartilhar experiências.

Tentaremos pegar um data center LAN DC de tamanho médio e elaborar todo o esquema de automação.
Farei algumas coisas quase pela primeira vez com você.

Não serei original nas ideias e ferramentas descritas aqui. Dmitry Figol tem um excelente canal com streams sobre este tema.
Os artigos irão se sobrepor a eles em muitos aspectos.

O LAN DC possui 4 DCs, cerca de 250 switches, meia dúzia de roteadores e alguns firewalls.
Não o Facebook, mas o suficiente para fazer você pensar profundamente sobre automação.
Existe, porém, a opinião de que se você tiver mais de 1 dispositivo, a automação já é necessária.
Na verdade, é difícil imaginar que alguém possa agora viver sem pelo menos um pacote de roteiros.
Embora eu tenha ouvido falar que existem escritórios onde os endereços IP são mantidos no Excel, e cada um dos milhares de dispositivos de rede é configurado manualmente e tem sua própria configuração exclusiva. É claro que isso pode ser considerado arte moderna, mas os sentimentos do engenheiro certamente ficarão ofendidos.

Objetivos

Agora definiremos os objetivos mais abstratos:

• A rede é como um único organismo
• Teste de configuração
• Versionamento de estado de rede
• Monitoramento e autocorreção de serviços

Mais adiante neste artigo veremos quais meios usaremos e, a seguir, veremos detalhadamente os objetivos e meios.

A rede é como um único organismo

A frase definidora da série, embora à primeira vista possa não parecer tão significativa: vamos configurar a rede, não os dispositivos individuais.
Nos últimos anos, temos assistido a uma mudança de ênfase no sentido de tratar a rede como uma entidade única, daí a Rede Definida por Software, Redes orientadas por intenção и Redes Autônomas.
Afinal, o que os aplicativos precisam globalmente da rede: conectividade entre os pontos A e B (bem, às vezes +B-Z) e isolamento de outros aplicativos e usuários.

E então nossa tarefa nesta série é construir um sistema, mantendo a configuração atual toda a rede, que já está decomposto na configuração real de cada dispositivo de acordo com sua função e localização.
Sistema o gerenciamento da rede implica que para fazer alterações entremos em contato com ele, e ele, por sua vez, calcula o estado desejado para cada dispositivo e o configura.
Desta forma, minimizamos o acesso manual à CLI a quase zero - quaisquer alterações nas configurações do dispositivo ou no design da rede devem ser formalizadas e documentadas - e só então implementadas nos elementos de rede necessários.

Isto é, por exemplo, se decidíssemos que a partir de agora os switches de rack em Kazan deveriam anunciar duas redes em vez de uma, nós

1. Primeiro documentamos mudanças nos sistemas
2. Gerando a configuração de destino de todos os dispositivos de rede
3. Lançamos o programa de atualização de configuração de rede, que calcula o que precisa ser removido em cada nó, o que adicionar e coloca os nós no estado desejado.

Ao mesmo tempo, fazemos alterações manualmente apenas na primeira etapa.

Teste de configuração

É conhecidoque 80% dos problemas ocorrem durante mudanças de configuração - uma prova indireta disso é que durante os feriados de Ano Novo tudo costuma ficar calmo.
Eu testemunhei pessoalmente dezenas de paralisações globais devido a erro humano: o comando errado, a configuração foi executada no branch errado, a comunidade esqueceu, o MPLS foi demolido globalmente no roteador, cinco peças de hardware foram configuradas, mas o erro não foi notei no sexto que alterações antigas feitas por outra pessoa foram cometidas. Existem muitos cenários.

A automação nos permitirá cometer menos erros, mas em maior escala. Dessa forma, você pode bloquear não apenas um dispositivo, mas toda a rede de uma só vez.

Desde tempos imemoriais, nossos avós verificaram com olhar atento a exatidão das alterações feitas, bolas de aço e a funcionalidade da rede após sua implementação.
Os avôs cujo trabalho levou a paralisações e perdas catastróficas deixaram menos descendentes e deveriam morrer com o tempo, mas a evolução é um processo lento e, portanto, nem todos ainda testam primeiro as mudanças no laboratório.
No entanto, na vanguarda do progresso estão aqueles que automatizaram o processo de teste da configuração e sua posterior aplicação à rede. Em outras palavras, peguei emprestado o procedimento CI/CD (Integração Contínua, Implantação Contínua) dos desenvolvedores.
Em uma das partes veremos como implementar isso usando um sistema de controle de versão, provavelmente o Github.

Depois que você se acostumar com a ideia de CI/CD de rede, da noite para o dia o método de verificar uma configuração aplicando-a a uma rede de produção parecerá uma ignorância medieval. É como acertar uma ogiva com um martelo.

Uma continuação orgânica de ideias sobre sistema o gerenciamento de rede e CI/CD torna-se um versionamento completo da configuração.

Versionamento

Assumiremos que com qualquer alteração, por menor que seja, mesmo em um dispositivo imperceptível, toda a rede passa de um estado para outro.
E nem sempre executamos um comando no aparelho, mudamos o estado da rede.
Então vamos chamar esses estados de versões?

Digamos que a versão atual seja 1.0.0.
O endereço IP da interface Loopback em um dos ToRs mudou? Esta é uma versão secundária e será numerada como 1.0.1.
Revisamos as políticas de importação de rotas para BGP - um pouco mais a sério - já 1.1.0
Decidimos nos livrar do IGP e mudar apenas para o BGP - esta já é uma mudança radical de design - 2.0.0.

Ao mesmo tempo, diferentes DCs podem ter versões diferentes - a rede está se desenvolvendo, novos equipamentos estão sendo instalados, novos níveis de espinhos estão sendo adicionados em algum lugar, em outros não, etc.

Про versionamento semântico falaremos em um artigo separado.

Repito - qualquer alteração (exceto comandos de depuração) é uma atualização de versão. Os administradores devem ser notificados sobre quaisquer desvios da versão atual.

O mesmo se aplica à reversão de alterações - isso não é o cancelamento dos últimos comandos, não é uma reversão usando o sistema operacional do dispositivo - isso é trazer toda a rede para uma nova (antiga) versão.

Monitoramento e autocorreção de serviços

Esta tarefa evidente atingiu um novo nível nas redes modernas.
Freqüentemente, os grandes provedores de serviços adotam a abordagem de que um serviço com falha precisa ser consertado muito rapidamente e um novo criado, em vez de descobrir o que aconteceu.
“Muito” significa que você precisa ser generosamente revestido por todos os lados com monitoramento, que em segundos detectará os menores desvios da norma.
E aqui as métricas usuais, como carregamento da interface ou disponibilidade do nó, não são mais suficientes. O monitoramento manual deles pelo oficial de plantão também não é suficiente.
Para muitas coisas deveria haver Autocura - as luzes de monitoramento ficaram vermelhas e nós mesmos aplicamos a banana onde doía.

E aqui também monitoramos não apenas dispositivos individuais, mas também a saúde de toda a rede, tanto a caixa branca, que é relativamente compreensível, quanto a caixa preta, que é mais complicada.

O que precisaremos para implementar planos tão ambiciosos?

• Tenha uma lista de todos os dispositivos da rede, sua localização, funções, modelos e versões de software.
  kazan-leaf-1.lmu.net, Kazan, folha, Juniper QFX 5120, R18.3.
• Tenha um sistema para descrever serviços de rede.
  IGP, BGP, L2/3VPN, Política, ACL, NTP, SSH.
• Ser capaz de inicializar o dispositivo.
  Nome do host, IP de gerenciamento, rota de gerenciamento, usuários, chaves RSA, LLDP, NETCONF
• Configure o dispositivo e traga a configuração para a versão desejada (inclusive a antiga).
• Configuração de teste
• Verifique periodicamente o status de todos os dispositivos em busca de desvios dos atuais e informe a quem deveria estar.
  Durante a noite, alguém adicionou discretamente uma regra à ACL.
• Monitore o desempenho.

Fundos

Parece complicado o suficiente para começar a decompor o projeto em componentes.

E serão dez deles:

1. sistema de inventário
2. Sistema de gerenciamento de espaço IP
3. Sistema de descrição de serviço de rede
4. Mecanismo de inicialização do dispositivo
5. Modelo de configuração independente de fornecedor
6. Interface de driver específica do fornecedor
7. Mecanismo para entregar configuração ao dispositivo
8. CI / CD
9. Mecanismo de backup e busca de desvios
10. Sistema de monitoramento

A propósito, este é um exemplo de como a visão sobre os objetivos do ciclo mudou - havia 4 componentes no rascunho.

Na ilustração descrevi todos os componentes e o próprio dispositivo.
Os componentes que se cruzam interagem entre si.
Quanto maior o bloco, mais atenção deve ser dada a este componente.

Componente 1: Sistema de inventário

Obviamente, queremos saber quais equipamentos estão localizados, onde e a que estão conectados.
O sistema de inventário é parte integrante de qualquer empresa.
Na maioria das vezes, uma empresa possui um sistema de inventário separado para dispositivos de rede, que resolve problemas mais específicos.
Como parte desta série de artigos, chamaremos isso de DCIM – Data Center Infrastructure Management. Embora o próprio termo DCIM, estritamente falando, inclua muito mais.

Para nossos propósitos, armazenaremos nele as seguintes informações sobre o dispositivo:

• Número do inventário
• Descrição do título
• Modelo (Huawei CE12800, zimbro QFX5120, etc.)
• Parâmetros característicos (placas, interfaces, etc.)
• Papel (Folha, lombada, roteador de borda, etc.)
• Localização (região, cidade, data center, rack, unidade)
• Interconexões entre dispositivos
• Topologia de rede

É perfeitamente claro que nós mesmos queremos saber tudo isso.
Mas isso ajudará para fins de automação?
Certamente.
Por exemplo, sabemos que em um determinado data center em switches Leaf, se for Huawei, ACLs para filtrar determinado tráfego deverão ser aplicadas na VLAN, e se for Juniper, então na unidade 0 da interface física.
Ou você precisa implementar um novo servidor Syslog em todas as fronteiras da região.

Nele armazenaremos dispositivos de rede virtuais, por exemplo roteadores virtuais ou refletores de raiz. Podemos adicionar servidores DNS, NTP, Syslog e em geral tudo que de uma forma ou de outra se relaciona com a rede.

Componente 2: Sistema de gerenciamento de espaço IP

Sim, e hoje em dia existem equipes que monitoram prefixos e endereços IP em um arquivo Excel. Mas a abordagem moderna ainda é um banco de dados, com front-end em nginx/apache, API e extensas funções para registro de endereços IP e redes divididas em VRFs.
IPAM - Gerenciamento de endereços IP.

Para nossos propósitos, armazenaremos as seguintes informações nele:

• VLAN
• VRF
• Redes/sub-redes
• Endereços IP
• Vinculando endereços a dispositivos, redes a locais e números de VLAN

Novamente, está claro que queremos ter certeza de que, ao alocarmos um novo endereço IP para o loopback ToR, não tropeçaremos no fato de que ele já foi atribuído a alguém. Ou que usamos o mesmo prefixo duas vezes em extremidades diferentes da rede.
Mas como isso ajuda na automação?
Fácil
Solicitamos um prefixo no sistema com a função Loopbacks, que contém os endereços IP disponíveis para alocação – caso seja encontrado, alocamos o endereço, caso contrário, solicitamos a criação de um novo prefixo.
Ou ao criar uma configuração de dispositivo, podemos descobrir no mesmo sistema em qual VRF a interface deve estar localizada.
E ao iniciar um novo servidor, o script faz login no sistema, descobre em qual switch o servidor está, em qual porta e qual sub-rede está atribuída à interface - e alocará o endereço do servidor a partir dele.

Isto sugere um desejo de combinar DCIM e IPAM em um sistema para não duplicar funções e não servir duas entidades semelhantes.
Isso é o que faremos.

Componente 3. Sistema para descrição de serviços de rede

Se os dois primeiros sistemas armazenam variáveis ​​que ainda precisam ser utilizadas de alguma forma, o terceiro descreve para cada função de dispositivo como ela deve ser configurada.
Vale a pena distinguir dois tipos diferentes de serviços de rede:

• A infraestrutura
• Cliente.

Os primeiros são projetados para fornecer conectividade básica e controle de dispositivos. Estes incluem VTY, SNMP, NTP, Syslog, AAA, protocolos de roteamento, CoPP, etc.
Estes últimos organizam o serviço para o cliente: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etc.
Claro, também existem casos limítrofes - onde incluir MPLS LDP, BGP? Sim, e protocolos de roteamento podem ser usados ​​para clientes. Mas isso não é importante.

Ambos os tipos de serviços são decompostos em primitivas de configuração:

• interfaces físicas e lógicas (tag/anteg, mtu)
• Endereços IP e VRFs (IP, IPv6, VRF)
• ACLs e políticas de processamento de tráfego
• Protocolos (IGP, BGP, MPLS)
• Políticas de roteamento (listas de prefixos, comunidades, filtros ASN).
• Serviços utilitários (SSH, NTP, LLDP, Syslog...)
• Etc.

Como exatamente faremos isso, ainda não tenho ideia. Veremos isso em um artigo separado.

Se um pouco mais perto da vida, então poderíamos descrever isso
O switch Leaf deve ter sessões BGP com todos os switches Spine conectados, importar redes conectadas para o processo e aceitar apenas redes de um determinado prefixo dos switches Spine. Limite CoPP IPv6 ND a 10 pps, etc.
Por sua vez, os espinhos realizam sessões com todos os leads conectados, atuando como refletores de raiz, e aceitam deles apenas rotas de certa extensão e com uma determinada comunidade.

Componente 4: Mecanismo de inicialização do dispositivo

Sob este título combino muitas das ações que devem ocorrer para que um dispositivo apareça no radar e seja acessado remotamente.

1. Insira o dispositivo no sistema de inventário.
2. Selecione um endereço IP de gerenciamento.
3. Configure o acesso básico a ele:
   Nome do host, endereço IP de gerenciamento, rota para a rede de gerenciamento, usuários, chaves SSH, protocolos - telnet/SSH/NETCONF

Existem três abordagens:

• Tudo é totalmente manual. O aparelho é levado ao estande, onde uma pessoa orgânica comum irá inseri-lo nos sistemas, conectá-lo ao console e configurá-lo. Pode funcionar em pequenas redes estáticas.
• ZTP - Provisionamento Zero Touch. O hardware chegou, levantou-se, recebeu um endereço via DHCP, foi para um servidor especial e se configurou.
• A infraestrutura dos servidores console, onde a configuração inicial ocorre através da porta console em modo automático.

Falaremos sobre todos os três em um artigo separado.

Componente 5: modelo de configuração independente de fornecedor

Até agora, todos os sistemas eram patches díspares que forneciam variáveis ​​e uma descrição declarativa do que gostaríamos de ver na rede. Mas, mais cedo ou mais tarde, você terá que lidar com detalhes.
Neste estágio, para cada dispositivo específico, primitivas, serviços e variáveis ​​são combinadas em um modelo de configuração que realmente descreve a configuração completa de um dispositivo específico, apenas de maneira neutra em relação ao fornecedor.
O que esta etapa faz? Por que não criar imediatamente uma configuração de dispositivo que você possa simplesmente carregar?
Na verdade, isso resolve três problemas:

1. Não se adapte a uma interface específica para interagir com o dispositivo. Seja CLI, NETCONF, RESTCONF, SNMP – o modelo será o mesmo.
2. Não mantenha a quantidade de templates/scripts de acordo com a quantidade de fornecedores na rede, e se o design mudar, altere a mesma coisa em vários lugares.
3. Carregue a configuração do dispositivo (backup), coloque-a exatamente no mesmo modelo e compare diretamente a configuração alvo com a existente para calcular o delta e preparar um patch de configuração que irá alterar apenas as partes necessárias ou para identificar desvios.

Como resultado desta etapa, obtemos uma configuração independente do fornecedor.

Componente 6. Interface de driver específica do fornecedor

Você não deve se iludir com a esperança de que um dia será possível configurar um ciska exatamente da mesma maneira que um Juniper, simplesmente enviando exatamente as mesmas chamadas para eles. Apesar da crescente popularidade das whiteboxes e do surgimento do suporte para NETCONF, RESTCONF, OpenConfig, o conteúdo específico que esses protocolos entregam difere de fornecedor para fornecedor, e esta é uma de suas diferenças competitivas da qual eles não desistirão tão facilmente.
Isso é praticamente o mesmo que OpenContrail e OpenStack, que têm RestAPI como interface NorthBound, esperam chamadas completamente diferentes.

Assim, na quinta etapa, o modelo independente do fornecedor deve assumir a forma como será transferido para o hardware.
E aqui todos os meios são bons (não): CLI, NETCONF, RESTCONF, SNMP simplesmente.

Portanto, precisaremos de um driver que transfira o resultado da etapa anterior para o formato exigido por um fornecedor específico: um conjunto de comandos CLI, uma estrutura XML.

Componente 7. Mecanismo para entrega de configuração ao dispositivo

Geramos a configuração, mas ela ainda precisa ser entregue aos dispositivos – e, obviamente, não manualmente.
Em primeiro lugar, nos deparamos com a questão de que transporte usaremos? E hoje a escolha já não é pequena:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• API REST
• OpenFlow (embora seja uma exceção porque é uma forma de fornecer FIB, não configurações)

Vamos colocar os pontos aqui. CLI é legado. SNMP... tosse tosse.
RESTCONF ainda é um animal desconhecido; a API REST é suportada por quase ninguém. Portanto, focaremos no NETCONF da série.

Na verdade, como o leitor já entendeu, a esta altura já decidimos a interface – o resultado da etapa anterior já está apresentado no formato da interface que foi escolhida.

em segundo lugar, e com quais ferramentas faremos isso?
Também há uma grande escolha aqui:

• Script ou plataforma auto-escrito. Vamos nos armar com ncclient e asyncIO e fazer tudo sozinhos. Quanto nos custa construir um sistema de implantação do zero?
• Ansible com sua rica biblioteca de módulos de rede.
• Sal com seu escasso trabalho com a rede e conexão com o Napalm.
• Na verdade Napalm, que conhece alguns fornecedores e pronto, adeus.
• Nornir é outro animal que dissecaremos no futuro.

Aqui o favorito ainda não foi escolhido - estaremos pesquisando.

O que mais é importante aqui? Consequências da aplicação da configuração.
Bem sucedido ou não. Ainda há acesso ao hardware ou não?
Parece que o commit vai ajudar aqui na confirmação e validação do que foi baixado no dispositivo.
Isto, combinado com a implementação correta do NETCONF, restringe significativamente a gama de dispositivos adequados - poucos fabricantes suportam commits normais. Mas este é apenas um dos pré-requisitos para RFP. No final das contas, ninguém está preocupado com o fato de nenhum fornecedor russo cumprir a condição de interface 32*100GE. Ou ele está preocupado?

Componente 8. CI/CD

Neste ponto já temos a configuração pronta para todos os dispositivos de rede.
Escrevo “para tudo” porque estamos falando de versionamento do estado da rede. E mesmo que seja necessário alterar as configurações de apenas um switch, as alterações são calculadas para toda a rede. Obviamente, eles podem ser zero para a maioria dos nós.

Mas, como já foi dito acima, não somos uma espécie de bárbaros que querem colocar tudo direto na produção.
A configuração gerada deve primeiro passar pelo Pipeline CI/CD.

CI/CD significa Integração Contínua, Implantação Contínua. Esta é uma abordagem na qual a equipe não apenas lança uma nova versão principal a cada seis meses, substituindo completamente a antiga, mas regularmente introduz de forma incremental (Implantação) novas funcionalidades em pequenas porções, cada uma das quais é exaustivamente testada quanto à compatibilidade, segurança e desempenho (Integração).

Para isso, contamos com um sistema de controle de versão que monitora as alterações de configuração, um laboratório que verifica se o atendimento ao cliente está quebrado, um sistema de monitoramento que verifica esse fato e a última etapa é implementar as alterações na rede de produção.

Com exceção dos comandos de depuração, absolutamente todas as alterações na rede devem passar pelo Pipeline CI/CD - esta é a nossa garantia de uma vida tranquila e de uma carreira longa e feliz.

Componente 9. Sistema de backup e detecção de anomalias

Bem, não há necessidade de falar sobre backups novamente.
Iremos simplesmente adicioná-los à coroa ou após uma mudança de configuração no git.

Mas a segunda parte é mais interessante – alguém deveria ficar de olho nesses backups. E em alguns casos, esse alguém deve ir e virar tudo como estava, e em outros, miar para alguém que algo está errado.
Por exemplo, se apareceu um novo usuário que não está cadastrado nas variáveis, é necessário removê-lo do hack. E se for melhor não mexer em uma nova regra de firewall, talvez alguém tenha ativado a depuração, ou talvez o novo serviço, um desastrado, não tenha sido registrado de acordo com os regulamentos, mas as pessoas já aderiram.

Ainda não escaparemos de algum pequeno delta na escala de toda a rede, apesar de quaisquer sistemas de automação e da mão de aço da gestão. Para depurar problemas, ninguém adicionará configuração aos sistemas. Além disso, podem nem estar incluídos no modelo de configuração.

Por exemplo, uma regra de firewall para contar o número de pacotes por IP específico para localizar um problema é uma configuração temporária completamente comum.

Componente 10. Sistema de monitoramento

A princípio eu não iria abordar o tema monitoramento - ainda é um tema volumoso, polêmico e complexo. Mas à medida que as coisas progrediram, descobriu-se que isto era parte integrante da automação. E é impossível contornar isso, mesmo sem prática.

A evolução do pensamento é uma parte orgânica do processo CI/CD. Depois de implementar a configuração na rede, precisamos ser capazes de determinar se está tudo bem agora.
E não estamos falando apenas e não tanto sobre cronogramas de uso de interface ou disponibilidade de nós, mas sobre coisas mais sutis - a presença das rotas necessárias, atributos nelas, o número de sessões BGP, vizinhos OSPF, desempenho ponta a ponta de serviços sobrejacentes.
Os syslogs para o servidor externo pararam de somar, ou o agente SFlow quebrou, ou as quedas nas filas começaram a crescer, ou a conectividade entre algum par de prefixos foi quebrada?

Refletiremos sobre isso em um artigo separado.

Conclusão

Como base, escolhi um dos designs modernos de rede de data center - L3 Clos Fabric com BGP como protocolo de roteamento.
Desta vez construiremos a rede no Juniper, pois agora a interface do JunOs é um vanlove.

Vamos tornar nossa vida mais difícil usando apenas ferramentas de código aberto e uma rede de vários fornecedores - então, além da Juniper, escolherei mais uma pessoa sortuda ao longo do caminho.

O plano para as próximas publicações é mais ou menos assim:
Primeiro falarei sobre redes virtuais. Em primeiro lugar, porque quero e, em segundo lugar, porque sem isso o desenho da rede de infra-estruturas não ficará muito claro.
Depois, sobre o design da rede em si: topologia, roteamento, políticas.
Vamos montar um estande de laboratório.
Vamos pensar sobre isso e talvez praticar a inicialização do dispositivo na rede.
E depois sobre cada componente em detalhes íntimos.

E sim, não prometo encerrar este ciclo graciosamente com uma solução pronta. 🙂

Links úteis

• Antes de mergulhar na série, vale a pena ler o livro de Natasha Samoilenko Python para engenheiros de rede. E talvez passe curso.
• Também será útil ler RFC sobre o projeto de fábricas de data centers do Facebook, por Peter Lapukhov.
• A documentação da arquitetura lhe dará uma ideia de como funciona o Overlay SDN. Tecido de tungstênio (anteriormente Open Contrail).

Obrigado

Desfiladeiro Romano. Para comentários e edições.
Artem Chernobay. Para KDPV.

Fonte: habr.com