O SDSM rematou, pero o desexo incontrolable de escribir permanece.

Durante moitos anos, o noso irmán sufría por facer traballos rutineiros, cruzar os dedos antes de cometer e non durmir debido aos retrocesos nocturnos.
Pero os tempos escuros están chegando ao seu fin.

Con este artigo vou comezar unha serie sobre como me vese automatización.
No camiño, comprenderemos as etapas de automatización, almacenamento de variables, formalización do deseño, RestAPI, NETCONF, YANG, YDK e faremos moita programación.
Me significa que a) non é unha verdade obxectiva, b) non é incondicionalmente o mellor enfoque, c) a miña opinión, mesmo durante o movemento do primeiro ao último artigo, pode cambiar - para ser honesto, desde a fase de borrador ata publicación, reescribín todo completamente dúas veces.

Contido

1. Obxectivos
   1. A rede é como un único organismo
   2. Proba de configuración
   3. Versionado
   4. Seguimento e autocuración dos servizos

2. Medios
   1. Sistema de inventario
   2. Sistema de xestión de espazos IP
   3. Sistema de descrición do servizo de rede
   4. Mecanismo de inicialización do dispositivo
   5. Modelo de configuración independente do provedor
   6. Interface de controlador específica do provedor
   7. Mecanismo para entregar a configuración ao dispositivo
   8. CI / CD
   9. Mecanismo de copia de seguridade e busca de desviacións
   10. Sistema de vixilancia

3. Conclusión

Tentarei realizar ADSM nun formato lixeiramente diferente do SDSM. Seguirán aparecendo artigos grandes, detallados e numerados, e entre eles publicarei pequenas notas da experiencia cotiá. Tentarei loitar contra o perfeccionismo aquí e non lamber cada un deles.

Que curioso é que a segunda vez teñas que pasar polo mesmo camiño.

Ao principio tiven que escribir eu mesmo artigos sobre redes debido a que non estaban na RuNet.

Agora non podía atopar un documento completo que sistematizase enfoques para a automatización e analizase as tecnoloxías anteriores utilizando exemplos prácticos sinxelos.

Pode que me equivoque, así que, por favor, proporcione ligazóns a recursos útiles. Non obstante, isto non vai cambiar a miña determinación de escribir, porque o obxectivo principal é aprender algo eu mesmo, e facilitarlles a vida aos demais é un bono agradable que acaricia o xene para compartir experiencia.

Tentaremos tomar un centro de datos LAN DC de tamaño medio e elaborar todo o esquema de automatización.
Vou facer algunhas cousas case por primeira vez contigo.

Non vou ser orixinal nas ideas e ferramentas aquí descritas. Dmitry Figol ten un excelente canle con emisións sobre este tema.
Os artigos solaparanse con eles en moitos aspectos.

A LAN DC ten 4 DC, uns 250 switches, media ducia de enrutadores e un par de firewalls.
Non Facebook, pero o suficiente para facerche pensar profundamente sobre a automatización.
Non obstante, existe a opinión de que se tes máis de 1 dispositivo, a automatización xa é necesaria.
De feito, é difícil imaxinar que agora alguén poida vivir sen polo menos un paquete de guións de xeonllos.
Aínda que escoitei que hai oficinas onde se gardan enderezos IP en Excel, e cada un dos miles de dispositivos de rede está configurado manualmente e ten a súa propia configuración única. Isto, por suposto, pode facerse pasar por arte moderna, pero os sentimentos do enxeñeiro definitivamente serán ofendidos.

Obxectivos

Agora marcaremos os obxectivos máis abstractos:

• A rede é como un único organismo
• Proba de configuración
• Versionado do estado da rede
• Seguimento e autocuración dos servizos

Máis adiante neste artigo analizaremos os medios que utilizaremos e, a continuación, analizaremos os obxectivos e os medios en detalle.

A rede é como un único organismo

A frase definitoria da serie, aínda que a primeira vista poida non parecer tan significativa: configuraremos a rede, non os dispositivos individuais.
Nos últimos anos, observamos un cambio de énfase para tratar a rede como unha única entidade, de aí o Software definido de rede, Redes impulsadas por intencións и Redes Autonómicas.
Despois de todo, que necesitan as aplicacións globalmente da rede: conectividade entre os puntos A e B (ben, ás veces +B-Z) e illamento doutras aplicacións e usuarios.

E así é a nosa tarefa nesta serie construír un sistema, mantendo a configuración actual toda a rede, que xa está descomposto na configuración real de cada dispositivo segundo a súa función e localización.
Sistema a xestión da rede implica que para facer cambios nos poñamos en contacto con ela, e este, á súa vez, calcula o estado desexado para cada dispositivo e configúrao.
Deste xeito, minimizamos o acceso manual á CLI a case cero -calquera cambio na configuración do dispositivo ou no deseño da rede debe ser formalizado e documentado- e só despois implementado aos elementos de rede necesarios.

É dicir, por exemplo, se decidimos que a partir de agora os interruptores de rack en Kazán anunciasen dúas redes en lugar dunha,

1. Primeiro documentamos os cambios nos sistemas
2. Xerando a configuración de destino de todos os dispositivos de rede
3. Lanzamos o programa de actualización da configuración da rede, que calcula o que hai que eliminar en cada nodo, o que engadir e leva os nodos ao estado desexado.

Ao mesmo tempo, facemos cambios manualmente só no primeiro paso.

Proba de configuración

Coñecidoque o 80% dos problemas ocorren durante os cambios de configuración; evidencia indirecta diso é que durante as vacacións de Ano Novo adoita estar todo tranquilo.
Persoalmente fun testemuña de ducias de paradas globais debido a un erro humano: o comando incorrecto, a configuración executouse na rama incorrecta, a comunidade esqueceuse, MPLS foi demolido globalmente no enrutador, configuráronse cinco pezas de hardware, pero o erro non foi. notado o sexto, cometéronse cambios antigos feitos por outra persoa. Hai un montón de escenarios.

A automatización permitiranos cometer menos erros, pero a maior escala. Deste xeito, podes facer ladrillos non só dun dispositivo, senón de toda a rede á vez.

Dende tempos inmemoriais, os nosos avós comprobaban a corrección dos cambios realizados con ollo agudo, bolas de aceiro e a funcionalidade da rede tras a súa posta en marcha.
Aqueles avós cuxo traballo levou a tempo de inactividade e perdas catastróficas deixaron menos descendencia e deberían morrer co paso do tempo, pero a evolución é un proceso lento e, polo tanto, non todo o mundo segue probando cambios no laboratorio primeiro.
Non obstante, á vangarda do progreso están os que automatizaron o proceso de proba da configuración e a súa posterior aplicación á rede. Noutras palabras, peguei prestado o procedemento CI/CD (Integración continua, implantación continua) dos desenvolvedores.
Nunha das partes veremos como implementar isto usando un sistema de control de versións, probablemente Github.

Unha vez que te acostumbres á idea de CI/CD de rede, o método de verificar unha configuración aplicándoa a unha rede de produción da noite para a mañá parecerá ignorancia medieval. Algo así como golpear unha oxiva cun martelo.

Unha continuación orgánica de ideas sobre sistema xestión de rede e CI/CD convértese nunha versión completa da configuración.

Versionado

Asumiremos que con calquera cambio, por pequeno que sexa, mesmo nun dispositivo imperceptible, toda a rede pasa dun estado a outro.
E non sempre executamos un comando no dispositivo, cambiamos o estado da rede.
Entón, imos chamar a estes estados versións?

Digamos que a versión actual é 1.0.0.
Cambiou o enderezo IP da interface Loopback nun dos ToR? Esta é unha versión menor e levará o número 1.0.1.
Revisamos as políticas para importar rutas a BGP - un pouco máis en serio - xa 1.1.0
Decidimos desfacernos de IGP e cambiar só a BGP - este xa é un cambio radical de deseño - 2.0.0.

Ao mesmo tempo, os diferentes DC poden ter versións diferentes: a rede estase a desenvolver, estanse instalando novos equipos, engádense novos niveis de espiñas nalgún lugar, non noutros, etc.

en versión semántica falaremos nun artigo aparte.

Repito: calquera cambio (excepto os comandos de depuración) é unha actualización de versión. Os administradores deben ser notificados de calquera desviación da versión actual.

O mesmo aplícase aos cambios retrotraídos: isto non é cancelar os últimos comandos, non é un retroceso usando o sistema operativo do dispositivo; isto está levando toda a rede a unha versión nova (vella).

Seguimento e autocuración dos servizos

Esta tarefa evidente por si mesma alcanzou un novo nivel nas redes modernas.
Moitas veces, os grandes provedores de servizos adoptan o enfoque de que un servizo fallado debe ser solucionado moi rapidamente e un novo levantado, en lugar de descubrir o que pasou.
"Moi" significa que ten que ser xenerosamente revestido por todos os lados con seguimento, que en segundos detectará as mínimas desviacións da norma.
E aquí as métricas habituais, como a carga da interface ou a dispoñibilidade de nodos, xa non son suficientes. Tampouco é suficiente o seguimento manual dos mesmos por parte do oficial de servizo.
Por moitas cousas debería haber Autocuración — as luces de vixilancia puxéronse en vermello e fomos aplicar nós o plátano onde doía.

E aquí tamén supervisamos non só os dispositivos individuais, senón tamén a saúde de toda a rede, tanto a caixa branca, que é relativamente comprensible, como a caixa negra, que é máis complicada.

Que necesitaremos para implementar plans tan ambiciosos?

• Ten unha lista de todos os dispositivos da rede, a súa localización, funcións, modelos e versións de software.
  kazan-leaf-1.lmu.net, Kazan, folla, Juniper QFX 5120, R18.3.
• Dispoñer dun sistema para describir servizos de rede.
  IGP, BGP, L2/3VPN, Política, ACL, NTP, SSH.
• Poder inicializar o dispositivo.
  Nome de host, IP de xestión, ruta de xestión, usuarios, claves RSA, LLDP, NETCONF
• Configura o dispositivo e leva a configuración á versión desexada (incluída a antiga).
• Configuración de proba
• Comprobe periodicamente o estado de todos os dispositivos para detectar desviacións dos actuais e informe a quen debe ser.
  Durante a noite, alguén engadiu silenciosamente unha regra á ACL.
• Supervisar o rendemento.

Medios

Parece o suficientemente complicado como para comezar a descompoñer o proxecto en compoñentes.

E serán dez:

1. Sistema de inventario
2. Sistema de xestión de espazos IP
3. Sistema de descrición do servizo de rede
4. Mecanismo de inicialización do dispositivo
5. Modelo de configuración independente do provedor
6. Interface de controlador específica do provedor
7. Mecanismo para entregar a configuración ao dispositivo
8. CI / CD
9. Mecanismo de copia de seguridade e busca de desviacións
10. Sistema de vixilancia

Este, por certo, é un exemplo de como cambiou a visión sobre os obxectivos do ciclo: había 4 compoñentes no borrador.

Na ilustración representei todos os compoñentes e o propio dispositivo.
Os compoñentes que se cruzan interactúan entre si.
Canto maior sexa o bloque, máis atención hai que prestar a este compoñente.

Compoñente 1: Sistema de inventarios

Obviamente, queremos saber que equipamento está situado onde, a que está conectado.
O sistema de inventario é unha parte integrante de calquera empresa.
Na maioría das veces, unha empresa ten un sistema de inventario separado para dispositivos de rede, que resolve problemas máis específicos.
Como parte desta serie de artigos, chamarémolo DCIM - Data Center Infrastructure Management. Aínda que o propio termo DCIM, en rigor, inclúe moito máis.

Para os nosos propósitos, almacenaremos nel a seguinte información sobre o dispositivo:

• Número de inventario
• Título/Descrición
• Modelo (Huawei CE12800, Juniper QFX5120, etc.)
• Parámetros característicos (placas, interfaces, etc.)
• Papel (Leaf, Spine, Border Router, etc.)
• Localización (rexión, cidade, centro de datos, rack, unidade)
• Interconexións entre dispositivos
• Topoloxía de rede

Está perfectamente claro que nós mesmos queremos saber todo isto.
Pero isto axudará a automatizarse?
Certamente.
Por exemplo, sabemos que nun determinado centro de datos en conmutadores Leaf, se é Huawei, deberían aplicarse ACL para filtrar certo tráfico na VLAN e, se é Juniper, na unidade 0 da interface física.
Ou cómpre lanzar un novo servidor Syslog a todas as fronteiras da rexión.

Nela almacenaremos dispositivos de rede virtuais, por exemplo routers virtuais ou reflectores de raíz. Podemos engadir servidores DNS, NTP, Syslog e en xeral todo o que dun xeito ou outro teña relación coa rede.

Compoñente 2: sistema de xestión do espazo IP

Si, e hoxe en día hai equipos de persoas que fan un seguimento dos prefixos e enderezos IP nun ficheiro Excel. Pero o enfoque moderno segue sendo unha base de datos, cun front-end en nginx/apache, API e amplas funcións para rexistrar enderezos IP e redes divididas en VRF.
IPAM - Xestión de enderezos IP.

Para os nosos efectos, almacenaremos nela a seguinte información:

• VLAN
• VRF
• Redes/Subredes
• enderezos IP
• Vinculación de enderezos a dispositivos, redes a localizacións e números de VLAN

De novo, está claro que queremos asegurarnos de que cando asignemos un novo enderezo IP para o loopback ToR, non tropezaremos co feito de que xa se lle asignou a alguén. Ou que usamos o mesmo prefixo dúas veces en diferentes extremos da rede.
Pero como axuda isto coa automatización?
É doado.
Solicitamos un prefixo no sistema co rol de Loopbacks, que contén enderezos IP dispoñibles para a súa asignación; se se atopa, asignamos o enderezo, se non, solicitamos a creación dun novo prefixo.
Ou ao crear unha configuración de dispositivo, podemos saber dende o mesmo sistema en que VRF debe estar a interface.
E ao iniciar un novo servidor, o script inicia sesión no sistema, descobre en que interruptor está o servidor, que porto e que subrede está asignada á interface e asignará o enderezo do servidor desde ela.

Isto suxire o desexo de combinar DCIM e IPAM nun só sistema para non duplicar funcións e non servir a dúas entidades similares.
Iso é o que faremos.

Compoñente 3. Sistema de descrición de servizos de rede

Se os dous primeiros sistemas almacenan variables que aínda deben usarse dalgún xeito, entón o terceiro describe para cada rol do dispositivo como debe configurarse.
Paga a pena distinguir dous tipos diferentes de servizos de rede:

• Infraestrutura
• Clienta.

Os primeiros están deseñados para proporcionar conectividade básica e control do dispositivo. Estes inclúen VTY, SNMP, NTP, Syslog, AAA, protocolos de enrutamento, CoPP, etc.
Estes últimos organizan o servizo para o cliente: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etc.
Por suposto, tamén hai casos límite: onde incluír MPLS LDP, BGP? Si, e os protocolos de enrutamento pódense usar para os clientes. Pero isto non é importante.

Ambos tipos de servizos están descompostos en primitivas de configuración:

• interfaces físicas e lóxicas (tag/anteg, mtu)
• Enderezos IP e VRF (IP, IPv6, VRF)
• ACL e políticas de procesamento de tráfico
• Protocolos (IGP, BGP, MPLS)
• Políticas de enrutamento (listas de prefixos, comunidades, filtros ASN).
• Servizos de utilidade (SSH, NTP, LLDP, Syslog...)
• Etc.

Como o faremos exactamente, aínda non teño nin idea. Analizarémolo nun artigo separado.

Se un pouco máis preto da vida, entón poderiamos describir iso
O interruptor Leaf debe ter sesións BGP con todos os interruptores Spine conectados, importar redes conectadas ao proceso e aceptar só redes dun determinado prefixo dos interruptores Spine. Limite CoPP IPv6 ND a 10 pps, etc.
Á súa vez, as espiñas realizan sesións con todos os cables conectados, actuando como reflectores de raíz, e aceptan deles só rutas de certa lonxitude e cunha determinada comunidade.

Compoñente 4: Mecanismo de inicialización do dispositivo

Baixo este epígrafe combino moitas das accións que deben producirse para que un dispositivo apareza no radar e se poida acceder de xeito remoto.

1. Introduza o dispositivo no sistema de inventario.
2. Seleccione un enderezo IP de xestión.
3. Configure o acceso básico a el:
   Nome de host, enderezo IP de xestión, ruta á rede de xestión, usuarios, claves SSH, protocolos - telnet/SSH/NETCONF

Hai tres enfoques:

• Todo é completamente manual. O dispositivo lévase ao stand, onde unha persoa orgánica común o introducirá nos sistemas, conectarase á consola e configuralo. Pode traballar en pequenas redes estáticas.
• ZTP - Aprovisionamento Zero Touch. O hardware chegou, ergueuse, recibiu un enderezo a través de DHCP, foi a un servidor especial e configurouse por si mesmo.
• A infraestrutura dos servidores de consola, onde a configuración inicial ocorre a través do porto da consola en modo automático.

Falaremos dos tres nun artigo separado.

Compoñente 5: modelo de configuración independente do provedor

Ata agora, todos os sistemas eran parches dispares que proporcionan variables e unha descrición declarativa do que nos gustaría ver na rede. Pero, tarde ou cedo, terás que tratar con detalles específicos.
Nesta fase, para cada dispositivo específico, as primitivas, servizos e variables combínanse nun modelo de configuración que realmente describe a configuración completa dun dispositivo específico, só de forma neutral para o provedor.
Que fai este paso? Por que non crear inmediatamente unha configuración de dispositivo que simplemente pode cargar?
De feito, isto resolve tres problemas:

1. Non te adaptes a unha interface específica para interactuar co dispositivo. Sexa CLI, NETCONF, RESTCONF, SNMP: o modelo será o mesmo.
2. Non manteñas o número de modelos/scripts segundo o número de provedores da rede e, se o deseño cambia, cambia o mesmo en varios lugares.
3. Cargue a configuración do dispositivo (backup), poñela exactamente no mesmo modelo e compare directamente a configuración de destino coa existente para calcular o delta e preparar un parche de configuración que cambiará só aquelas partes que sexan necesarias ou para identificar desviacións.

Como resultado desta etapa, obtemos unha configuración independente do provedor.

Compoñente 6. Interface de controlador específica do provedor

Non deberías halagarte coa esperanza de que algún día sexa posible configurar un ciska exactamente do mesmo xeito que un Juniper, simplemente enviándolles exactamente as mesmas chamadas. A pesar da crecente popularidade das caixas brancas e da aparición do soporte para NETCONF, RESTCONF, OpenConfig, o contido específico que ofrecen estes protocolos difire dun provedor a outro, e esta é unha das súas diferenzas competitivas á que non renunciarán tan facilmente.
Isto é aproximadamente o mesmo que OpenContrail e OpenStack, que teñen RestAPI como interface NorthBound, esperan chamadas completamente diferentes.

Polo tanto, no quinto paso, o modelo independente do provedor debe adoptar a forma na que pasará ao hardware.
E aquí todos os medios son bos (non): CLI, NETCONF, RESTCONF, SNMP simplemente.

Polo tanto, necesitaremos un controlador que transferirá o resultado do paso anterior ao formato necesario dun provedor específico: un conxunto de comandos CLI, unha estrutura XML.

Compoñente 7. Mecanismo de entrega de configuración ao dispositivo

Xeramos a configuración, pero aínda hai que entregala aos dispositivos e, obviamente, non a man.
En primeiro lugar, estamos ante a pregunta de que transporte usaremos? E hoxe a elección xa non é pequena:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• API REST
• OpenFlow (aínda que é un valor atípico porque é unha forma de entregar FIB, non a configuración)

Imos poñer a t aquí. CLI é un legado. SNMP... tose tose.
RESTCONF aínda é un animal descoñecido; case ninguén admite a API REST. Polo tanto, centrarémonos en NETCONF na serie.

De feito, como xa entendeu o lector, a estas alturas xa decidimos a interface: o resultado do paso anterior xa se presenta no formato da interface que se elixiu.

En segundo lugar, e con que ferramentas faremos isto?
Tamén hai unha gran variedade aquí:

• Guión ou plataforma autoescrito. Armémonos con ncclient e asyncIO e fagamos todo nós. Que nos custa construír un sistema de implantación dende cero?
• Ansible coa súa rica biblioteca de módulos de rede.
• Salt co seu escaso traballo coa rede e conexión con Napalm.
• En realidade Napalm, que coñece un par de vendedores e xa está, adeus.
• Nornir é outro animal que diseccionaremos no futuro.

Aquí aínda non se elixiu o favorito: estaremos a buscar.

Que máis é importante aquí? Consecuencias da aplicación da configuración.
Éxito ou non. Aínda hai acceso ao hardware ou non?
Parece que commit axudará aquí coa confirmación e validación do que se descargou no dispositivo.
Isto, combinado coa implementación correcta de NETCONF, reduce significativamente a gama de dispositivos axeitados; non moitos fabricantes admiten compromisos normais. Pero este é só un dos requisitos previos RFP. Ao final, a ninguén lle preocupa que ningún vendedor ruso cumpra a condición de interface 32 * 100GE. Ou está preocupado?

Compoñente 8. CI/CD

Neste punto, xa temos a configuración lista para todos os dispositivos da rede.
Escribo "para todo" porque estamos a falar de versionar o estado da rede. E aínda que necesites cambiar a configuración dun só interruptor, os cambios calcúlanse para toda a rede. Obviamente, poden ser cero para a maioría dos nós.

Pero, como xa se dixo máis arriba, non somos unha especie de bárbaros que queiramos tirar todo directamente á produción.
A configuración xerada debe pasar primeiro por Pipeline CI/CD.

CI/CD significa Continuous Integration, Continuous Deployment. Este é un enfoque no que o equipo non só publica unha nova versión principal cada seis meses, substituíndo completamente á antiga, senón que implementa de forma incremental e regular (Impregación) novas funcionalidades en pequenas porcións, cada unha das cales se proba exhaustivamente a compatibilidade, seguridade e rendemento (integración).

Para iso contamos cun sistema de control de versións que supervisa os cambios de configuración, un laboratorio que verifica se o servizo ao cliente está roto, un sistema de seguimento que verifica este feito e o último paso é implantar cambios na rede de produción.

Con excepción dos comandos de depuración, absolutamente todos os cambios na rede deben pasar pola canalización CI/CD: esta é a nosa garantía dunha vida tranquila e dunha carreira longa e feliz.

Compoñente 9. Sistema de copia de seguridade e detección de anomalías

Ben, non hai que falar de copias de seguridade de novo.
Simplemente poñerémolos en git de acordo coa coroa ou sobre o feito dun cambio de configuración.

Pero a segunda parte é máis interesante: alguén debería estar atento a estas copias de seguridade. E nalgúns casos, este alguén debe ir e darlle a volta a todo como estaba, e noutros, miaulle a alguén que algo anda mal.
Por exemplo, se apareceu un novo usuario que non está rexistrado nas variables, cómpre eliminalo do pirateo. E se é mellor non tocar unha nova regra de firewall, quizais alguén acaba de activar a depuración, ou quizais o novo servizo, un bungler, non se rexistrou segundo a normativa, pero a xente xa se uniu a el.

Aínda non escaparemos dalgún pequeno delta a escala de toda a rede, a pesar de calquera sistema de automatización e da man aceirada da xestión. Para depurar problemas, ninguén engadirá configuración aos sistemas de todos os xeitos. Ademais, poden nin sequera incluír no modelo de configuración.

Por exemplo, unha regra de firewall para contar o número de paquetes por IP específica para localizar un problema é unha configuración temporal completamente normal.

Compoñente 10. Sistema de vixilancia

Nun principio non ía tratar o tema da vixilancia: segue sendo un tema voluminoso, controvertido e complexo. Pero a medida que as cousas avanzaban, resultou que esta era unha parte integrante da automatización. E é imposible evitalo, mesmo sen práctica.

Evolving Thought é unha parte orgánica do proceso CI/CD. Despois de lanzar a configuración á rede, temos que ser capaces de determinar se agora está todo ben.
E estamos a falar non só e non tanto de programacións de uso da interface ou dispoñibilidade de nodos, senón de cousas máis sutís: a presenza das rutas necesarias, os atributos nelas, o número de sesións BGP, os veciños OSPF, o rendemento de extremo a extremo. dos servizos subxacentes.
Os syslogs do servidor externo deixaron de sumarse, ou o axente SFlow rompeu, ou as caídas nas filas comezaron a crecer, ou a conectividade entre algún par de prefixos romperon?

Reflexionaremos sobre isto nun artigo separado.

Conclusión

Como base, escollín un dos deseños modernos de rede de centros de datos: L3 Clos Fabric con BGP como protocolo de enrutamento.
Esta vez imos construír a rede en Juniper, porque agora a interface de JunOs é un vanlove.

Facemos a nosa vida máis difícil usando só ferramentas de código aberto e unha rede de varios provedores; así, ademais de Juniper, escollerei unha persoa máis afortunada no camiño.

O plan para as próximas publicacións é algo así:
Primeiro falarei das redes virtuais. En primeiro lugar, porque quero e, segundo, porque sen isto, o deseño da rede de infraestruturas non estará moi claro.
Despois sobre o deseño da rede en si: topoloxía, enrutamento, políticas.
Imos montar un stand de laboratorio.
Pensemos niso e quizais practiquemos a inicialización do dispositivo na rede.
E despois sobre cada compoñente nun detalle íntimo.

E si, non prometo rematar con graza este ciclo cunha solución preparada. 🙂

Ligazóns útiles

• Antes de afondar na serie, paga a pena ler o libro de Natasha Samoilenko Python para enxeñeiros de rede. E quizais pase o curso.
• Tamén será útil para ler RFC sobre o deseño de fábricas de centros de datos de Facebook por Peter Lapukhov.
• A documentación de arquitectura darache unha idea de como funciona Overlay SDN. Tecido de tungsteno (anteriormente Open Contrail).

Grazas

Garganta Romana. Para comentarios e edicións.
Artyom Chernobay. Para KDPV.

Fonte: www.habr.com