S'ha acabat SDSM, però el desig incontrolable d'escriure continua.

Durant molts anys, el nostre germà va patir per fer tasques rutinàries, creuar-se els dits abans de cometre i no dormir a causa dels retrocessos nocturns.
Però els temps foscos estan arribant a la seva fi.

Amb aquest article començaré una sèrie sobre com em apareix l'automatització.
Al llarg del camí, coneixerem les etapes d'automatització, emmagatzematge de variables, formalització del disseny, RestAPI, NETCONF, YANG, YDK i farem molta programació.
Em significa que a) no és una veritat objectiva, b) no és incondicionalment el millor enfocament, c) la meva opinió, fins i tot durant el moviment del primer a l'últim article, pot canviar, per ser honest, des de l'etapa d'esborrany fins a publicació, ho vaig reescriure tot completament dues vegades.

Contingut

1. Objectius
   1. La xarxa és com un únic organisme
   2. Prova de configuració
   3. Versioning
   4. Seguiment i autocuració dels serveis

2. Mitjans
   1. Sistema d'inventari
   2. Sistema de gestió de l'espai IP
   3. Sistema de descripció de serveis de xarxa
   4. Mecanisme d'inicialització del dispositiu
   5. Model de configuració independent del proveïdor
   6. Interfície de controlador específica del proveïdor
   7. Mecanisme per lliurar la configuració al dispositiu
   8. CI / CD
   9. Mecanisme de còpia de seguretat i recerca de desviacions
   10. Sistema de seguiment

3. Conclusió

Intentaré dur a terme l'ADSM en un format lleugerament diferent de l'SDSM. Continuaran apareixent articles grans, detallats i numerats, i entre ells publicaré petites notes de l'experiència quotidiana. Intentaré combatre el perfeccionisme aquí i no llepar-los tots.

Que curiós que la segona vegada hagis de passar pel mateix camí.

Al principi vaig haver d'escriure jo mateix articles sobre xarxes a causa del fet que no estaven a RuNet.

Ara no he pogut trobar un document complet que sistematitzi els enfocaments de l'automatització i analitzés les tecnologies anteriors utilitzant exemples pràctics senzills.

Potser m'equivoco, així que si us plau, proporcioneu enllaços a recursos útils. Tanmateix, això no canviarà la meva determinació d'escriure, perquè l'objectiu principal és aprendre alguna cosa jo mateix, i fer la vida més fàcil als altres és un avantatge agradable que acaricia el gen per compartir experiències.

Intentarem agafar un centre de dades LAN DC de mida mitjana i elaborar tot l'esquema d'automatització.
Faré algunes coses gairebé per primera vegada amb tu.

No seré original en les idees i les eines descrites aquí. Dmitry Figol té un excel·lent canal amb streams sobre aquest tema.
Els articles se superposaran amb ells en molts aspectes.

La LAN DC té 4 DC, uns 250 commutadors, mitja dotzena d'encaminadors i un parell de tallafocs.
No Facebook, però prou per fer-vos pensar profundament sobre l'automatització.
Hi ha, però, l'opinió que si tens més d'1 dispositiu, ja cal l'automatització.
De fet, és difícil imaginar que ara algú pugui viure sense almenys un paquet de guions de genoll.
Tot i que he sentit que hi ha oficines on les adreces IP es guarden a Excel, i cadascun dels milers de dispositius de xarxa es configura manualment i té la seva pròpia configuració única. Això, per descomptat, es pot passar per art modern, però els sentiments de l'enginyer definitivament es sentiran ofès.

Objectius

Ara establirem els objectius més abstractes:

• La xarxa és com un únic organisme
• Prova de configuració
• Versions de l'estat de la xarxa
• Seguiment i autocuració dels serveis

Més endavant en aquest article veurem quins mitjans utilitzarem i, a continuació, veurem els objectius i els mitjans en detall.

La xarxa és com un únic organisme

La frase definitòria de la sèrie, encara que a primera vista no sembli tan significativa: configurarem la xarxa, no els dispositius individuals.
En els darrers anys, hem vist un canvi en l'èmfasi cap a tractar la xarxa com una entitat única, d'aquí la Software Defined Networking, Xarxes impulsades per intencions и Xarxes Autònomes.
Al cap i a la fi, què necessiten les aplicacions globalment de la xarxa: connectivitat entre els punts A i B (bé, de vegades +B-Z) i aïllament d'altres aplicacions i usuaris.

I així és la nostra tasca en aquesta sèrie construir un sistema, mantenint la configuració actual tota la xarxa, que ja es descompon en la configuració real de cada dispositiu d'acord amb la seva funció i ubicació.
Sistema la gestió de la xarxa implica que per fer canvis ens posem en contacte amb ella, i aquesta, al seu torn, calcula l'estat desitjat per a cada dispositiu i el configura.
D'aquesta manera, minimitzem l'accés manual a la CLI a gairebé zero (qualsevol canvi en la configuració del dispositiu o el disseny de la xarxa s'ha de formalitzar i documentar) i només després es desplega als elements de xarxa necessaris.

És a dir, per exemple, si decidim que a partir d'ara els interruptors de bastidor de Kazan haurien d'anunciar dues xarxes en lloc d'una,

1. Primer documentem els canvis en els sistemes
2. Generació de la configuració de destinació de tots els dispositius de xarxa
3. Llencem el programa d'actualització de la configuració de xarxa, que calcula què cal eliminar de cada node, què afegir i porta els nodes a l'estat desitjat.

Al mateix temps, fem els canvis manualment només en el primer pas.

Prova de configuració

Es coneixque el 80% dels problemes es produeixen durant els canvis de configuració; una prova indirecta d'això és que durant les vacances d'Any Nou tot sol estar tranquil.
Personalment he presenciat desenes de temps d'inactivitat globals a causa d'un error humà: l'ordre equivocada, la configuració s'ha executat a la branca equivocada, la comunitat s'ha oblidat, MPLS es va enderrocar globalment al router, es van configurar cinc peces de maquinari, però l'error no es va fer. observat el sisè, es van cometre canvis antics fets per una altra persona. Hi ha un munt d'escenaris.

L'automatització ens permetrà cometre menys errors, però a més gran escala. D'aquesta manera, podeu crear no només un dispositiu, sinó tota la xarxa alhora.

Des de temps immemorials, els nostres avis van comprovar la correcció dels canvis fets amb bon ull, boles d'acer i la funcionalitat de la xarxa després de ser desplegats.
Aquells avis el treball dels quals va provocar temps d'inactivitat i pèrdues catastròfiques van deixar menys descendència i haurien d'extingir-se amb el temps, però l'evolució és un procés lent i, per tant, no tothom segueix provant els canvis al laboratori primer.
No obstant això, al capdavant del progrés hi ha aquells que han automatitzat el procés de prova de la configuració i la seva posterior aplicació a la xarxa. En altres paraules, vaig agafar en préstec el procediment CI/CD (Integració contínua, desplegament continu) dels desenvolupadors.
En una de les parts veurem com implementar-ho mitjançant un sistema de control de versions, probablement Github.

Un cop us acostumeu a la idea del CI/CD de xarxa, de la nit al dia el mètode de comprovar una configuració aplicant-la a una xarxa de producció semblarà una ignorància medieval. És com colpejar una ogiva amb un martell.

Una continuació orgànica d'idees sobre sistema gestió de xarxa i CI/CD es converteix en una versió completa de la configuració.

Versioning

Suposarem que amb qualsevol canvi, per petit que sigui, fins i tot en un dispositiu imperceptible, tota la xarxa es mou d'un estat a un altre.
I sempre no executem una ordre al dispositiu, canviem l'estat de la xarxa.
Aleshores, anomenem aquestes versions d'estats?

Suposem que la versió actual és la 1.0.0.
Ha canviat l'adreça IP de la interfície Loopback d'un dels ToR? Aquesta és una versió menor i es numerarà 1.0.1.
Hem revisat les polítiques per importar rutes a BGP, una mica més seriosament, ja 1.1.0
Vam decidir desfer-nos de l'IGP i canviar només a BGP - això ja és un canvi de disseny radical - 2.0.0.

Al mateix temps, diferents DC poden tenir diferents versions: la xarxa s'està desenvolupant, s'estan instal·lant nous equips, s'afegeixen nous nivells d'espines en algun lloc, no en altres, etc.

Про versionat semàntic en parlarem en un article a part.

Repeteixo: qualsevol canvi (excepte les ordres de depuració) és una actualització de versió. Els administradors han de ser notificats de qualsevol desviació de la versió actual.

El mateix s'aplica als canvis enrere: això no és cancel·lar les últimes ordres, no es tracta d'una recuperació utilitzant el sistema operatiu del dispositiu; això porta tota la xarxa a una versió nova (antiga).

Seguiment i autocuració dels serveis

Aquesta tasca evident ha assolit un nou nivell a les xarxes modernes.
Sovint, els grans proveïdors de serveis adopten l'enfocament que cal arreglar un servei fallit molt ràpidament i plantejar-ne un de nou, en lloc d'esbrinar què ha passat.
"Molt" vol dir que heu de revestir generosament tots els costats amb un control, que en qüestió de segons detectarà les més petites desviacions de la norma.
I aquí les mètriques habituals, com ara la càrrega de la interfície o la disponibilitat de nodes, ja no són suficients. Tampoc n'hi ha prou amb el seguiment manual per part de l'oficial de servei.
Per moltes coses n'hi hauria d'haver Autocuració — els llums de vigilància es van posar vermells i vam anar a aplicar el plàtan nosaltres mateixos on feia mal.

I aquí també controlem no només els dispositius individuals, sinó també la salut de tota la xarxa, tant la caixa blanca, que és relativament comprensible, com la caixa negra, que és més complicada.

Què necessitarem per implementar plans tan ambiciosos?

• Teniu una llista de tots els dispositius de la xarxa, la seva ubicació, rols, models, versions de programari.
  kazan-leaf-1.lmu.net, Kazan, fulla, Juniper QFX 5120, R18.3.
• Tenir un sistema per descriure els serveis de xarxa.
  IGP, BGP, L2/3VPN, Política, ACL, NTP, SSH.
• Ser capaç d'inicialitzar el dispositiu.
  Nom d'amfitrió, IP de gestió, ruta de gestió, usuaris, claus RSA, LLDP, NETCONF
• Configura el dispositiu i porta la configuració a la versió desitjada (inclosa l'antiga).
• Prova de configuració
• Comproveu periòdicament l'estat de tots els dispositius per detectar desviacions dels actuals i informa a qui hauria de ser.
  Durant la nit, algú va afegir silenciosament una regla a l'ACL.
• Supervisar el rendiment.

Mitjans

Sembla prou complicat com per començar a descompondre el projecte en components.

I n'hi haurà deu:

1. Sistema d'inventari
2. Sistema de gestió de l'espai IP
3. Sistema de descripció de serveis de xarxa
4. Mecanisme d'inicialització del dispositiu
5. Model de configuració independent del proveïdor
6. Interfície de controlador específica del proveïdor
7. Mecanisme per lliurar la configuració al dispositiu
8. CI / CD
9. Mecanisme de còpia de seguretat i recerca de desviacions
10. Sistema de seguiment

Aquest, per cert, és un exemple de com va canviar la visió sobre els objectius del cicle: hi havia 4 components a l'esborrany.

A la il·lustració vaig representar tots els components i el propi dispositiu.
Els components que s'intersequen interaccionen entre ells.
Com més gran sigui el bloc, més atenció cal parar a aquest component.

Component 1: Sistema d'inventari

Evidentment, volem saber quin equip es troba on, a què està connectat.
El sistema d'inventari és una part integral de qualsevol empresa.
Molt sovint, una empresa té un sistema d'inventari separat per a dispositius de xarxa, que resol problemes més específics.
Com a part d'aquesta sèrie d'articles, l'anomenarem DCIM - Data Center Infrastructure Management. Encara que el mateix terme DCIM, en sentit estricte, inclou molt més.

Per als nostres propòsits, emmagatzemarem la següent informació sobre el dispositiu:

• Número d'inventari
• Títol/Descripció
• Model (Huawei CE12800, Juniper QFX5120, etc.)
• Paràmetres característics (plaques, interfícies, etc.)
• Rol (Encaminador de fulla, columna vertebral, vora, etc.)
• Ubicació (regió, ciutat, centre de dades, bastidor, unitat)
• Interconnexions entre dispositius
• Topologia de xarxa

Està perfectament clar que nosaltres mateixos volem saber tot això.
Però això ajudarà amb finalitats d'automatització?
Per descomptat.
Per exemple, sabem que en un centre de dades determinat en commutadors Leaf, si és Huawei, les ACL per filtrar determinat trànsit s'han d'aplicar a la VLAN, i si és Juniper, a la unitat 0 de la interfície física.
O bé, heu de desplegar un nou servidor Syslog a totes les fronteres de la regió.

En ella emmagatzemarem dispositius de xarxa virtual, per exemple encaminadors virtuals o reflectors arrel. Hi podem afegir servidors DNS, NTP, Syslog i en general tot allò que d'una manera o altra es refereix a la xarxa.

Component 2: Sistema de gestió de l'espai IP

Sí, i avui dia hi ha equips de persones que fan un seguiment dels prefixos i adreces IP en un fitxer Excel. Però l'enfocament modern segueix sent una base de dades, amb un front-end a nginx/apache, API i àmplies funcions per registrar adreces IP i xarxes dividides en VRF.
IPAM - Gestió d'adreces IP.

Per als nostres propòsits, hi emmagatzemarem la següent informació:

• VLAN
• VRF
• Xarxes/Subxarxes
• adreces IP
• Vincular adreces a dispositius, xarxes a ubicacions i números de VLAN

De nou, està clar que volem assegurar-nos que quan assignem una nova adreça IP per al loopback ToR, no ens ensopegarem amb el fet que ja estava assignada a algú. O que hem fet servir el mateix prefix dues vegades a diferents extrems de la xarxa.
Però, com ajuda això amb l'automatització?
Fàcil
Sol·licitem un prefix al sistema amb la funció Loopbacks, que conté adreces IP disponibles per a l'assignació; si es troba, assignem l'adreça, si no, demanem la creació d'un nou prefix.
O quan es crea una configuració de dispositiu, podem esbrinar des del mateix sistema en quin VRF s'ha d'ubicar la interfície.
I quan s'inicia un nou servidor, l'script inicia sessió al sistema, descobreix a quin commutador es troba el servidor, quin port i quina subxarxa s'assigna a la interfície i n'assignarà l'adreça del servidor.

Això suggereix un desig de combinar DCIM i IPAM en un sol sistema per no duplicar funcions i no servir dues entitats similars.
Això és el que farem.

Component 3. Sistema de descripció de serveis de xarxa

Si els dos primers sistemes emmagatzemen variables que encara s'han d'utilitzar d'alguna manera, el tercer descriu per a cada funció del dispositiu com s'ha de configurar.
Val la pena distingir dos tipus diferents de serveis de xarxa:

• Infraestructura
• Client.

Els primers estan dissenyats per proporcionar connectivitat bàsica i control del dispositiu. Aquests inclouen VTY, SNMP, NTP, Syslog, AAA, protocols d'encaminament, CoPP, etc.
Aquests últims organitzen el servei per al client: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etc.
Per descomptat, també hi ha casos límit: on incloure MPLS LDP, BGP? Sí, i els protocols d'encaminament es poden utilitzar per als clients. Però això no és important.

Tots dos tipus de serveis es descomponen en primitives de configuració:

• interfícies físiques i lògiques (tag/anteg, mtu)
• Adreces IP i VRF (IP, IPv6, VRF)
• ACL i polítiques de processament de trànsit
• Protocols (IGP, BGP, MPLS)
• Polítiques d'encaminament (llistes de prefixos, comunitats, filtres ASN).
• Serveis d'utilitat (SSH, NTP, LLDP, Syslog...)
• Etc.

Com ho farem exactament, encara no en tinc ni idea. Ho analitzarem en un article a part.

Si una mica més a prop de la vida, podríem descriure-ho
El commutador Leaf ha de tenir sessions BGP amb tots els commutadors Spine connectats, importar xarxes connectades al procés i acceptar només xarxes d'un determinat prefix dels commutadors Spine. Limiteu CoPP IPv6 ND a 10 pps, etc.
Al seu torn, les espines fan sessions amb tots els cables connectats, actuant com a reflectors d'arrel, i accepten d'ells només rutes d'una certa longitud i amb una determinada comunitat.

Component 4: Mecanisme d'inicialització del dispositiu

Sota aquest títol combino moltes de les accions que s'han de produir perquè un dispositiu aparegui al radar i s'hi pugui accedir de forma remota.

1. Introduïu el dispositiu al sistema d'inventari.
2. Seleccioneu una adreça IP de gestió.
3. Configureu-hi l'accés bàsic:
   Nom d'amfitrió, adreça IP de gestió, ruta a la xarxa de gestió, usuaris, claus SSH, protocols - telnet/SSH/NETCONF

Hi ha tres enfocaments:

• Tot és totalment manual. El dispositiu es porta a l'estand, on una persona orgànica normal l'introduirà als sistemes, es connectarà a la consola i la configurarà. Pot treballar en petites xarxes estàtiques.
• ZTP - Provisionament Zero Touch. El maquinari va arribar, es va aixecar, va rebre una adreça mitjançant DHCP, va anar a un servidor especial i es va configurar.
• La infraestructura dels servidors de la consola, on la configuració inicial es produeix a través del port de la consola en mode automàtic.

En parlarem de tots tres en un article separat.

Component 5: model de configuració independent del proveïdor

Fins ara, tots els sistemes eren pedaços diferents que proporcionen variables i una descripció declarativa del que voldríem veure a la xarxa. Però, tard o d'hora, hauràs de tractar amb detalls.
En aquesta etapa, per a cada dispositiu específic, les primitives, els serveis i les variables es combinen en un model de configuració que descriu realment la configuració completa d'un dispositiu específic, només d'una manera neutral per al proveïdor.
Què fa aquest pas? Per què no creeu immediatament una configuració de dispositiu que simplement pugueu carregar?
De fet, això resol tres problemes:

1. No us adapteu a una interfície específica per interactuar amb el dispositiu. Ja sigui CLI, NETCONF, RESTCONF, SNMP, el model serà el mateix.
2. No mantingueu el nombre de plantilles/scripts segons el nombre de venedors de la xarxa, i si el disseny canvia, canvieu el mateix en diversos llocs.
3. Carregueu la configuració del dispositiu (còpia de seguretat), poseu-la exactament al mateix model i compareu directament la configuració de destinació amb l'existent per calcular el delta i preparar un pedaç de configuració que canviarà només aquelles parts que siguin necessàries o per identificar desviacions.

Com a resultat d'aquesta etapa, obtenim una configuració independent del proveïdor.

Component 6. Interfície de controlador específica del proveïdor

No us hauríeu d'afalagar amb l'esperança que algun dia sigui possible configurar un ciska exactament de la mateixa manera que un Juniper, simplement enviant-los exactament les mateixes trucades. Malgrat la creixent popularitat de les caixes blanques i l'aparició del suport per a NETCONF, RESTCONF, OpenConfig, el contingut específic que ofereixen aquests protocols difereix d'un proveïdor a un altre, i aquesta és una de les seves diferències competitives a la qual no renunciaran tan fàcilment.
Això és aproximadament el mateix que OpenContrail i OpenStack, que tenen RestAPI com a interfície NorthBound, esperen trucades completament diferents.

Per tant, en el cinquè pas, el model independent del venedor ha de prendre la forma en què anirà al maquinari.
I aquí tots els mitjans són bons (no): CLI, NETCONF, RESTCONF, SNMP simplement.

Per tant, necessitarem un controlador que transferirà el resultat del pas anterior al format requerit d'un proveïdor específic: un conjunt d'ordres CLI, una estructura XML.

Component 7. Mecanisme per lliurar la configuració al dispositiu

Hem generat la configuració, però encara s'ha de lliurar als dispositius i, òbviament, no a mà.
Primer, ens trobem davant la pregunta de quin transport utilitzarem? I avui l'elecció ja no és petita:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (tot i que és un valor atípic perquè és una manera de lliurar FIB, no configuracions)

Anem a puntejar la T aquí. CLI és un llegat. SNMP... tos tos.
RESTCONF encara és un animal desconegut; l'API REST és compatible amb gairebé ningú. Per tant, ens centrarem en NETCONF a la sèrie.

De fet, com el lector ja ha entès, en aquest punt ja hem decidit la interfície: el resultat del pas anterior ja es presenta en el format de la interfície que s'ha escollit.

En segon lloc, i amb quines eines ho farem?
També hi ha una gran selecció aquí:

• Guió o plataforma autoescrita. Armem-nos amb ncclient i asyncIO i fem-ho tot nosaltres mateixos. Què ens costa construir un sistema de desplegament des de zero?
• Ansible amb la seva rica biblioteca de mòduls de xarxa.
• Salt amb el seu escàs treball amb la xarxa i connexió amb Napalm.
• En realitat Napalm, que coneix un parell de venedors i ja està, adéu.
• Nornir és un altre animal que disseccionarem en el futur.

Aquí encara no s'ha escollit el favorit: buscarem.

Què més és important aquí? Conseqüències de l'aplicació de la configuració.
Encertat o no. Encara hi ha accés al maquinari o no?
Sembla que commit ajudarà aquí amb la confirmació i validació del que s'ha baixat al dispositiu.
Això, combinat amb la correcta implementació de NETCONF, redueix significativament la gamma de dispositius adequats; no molts fabricants admeten les commits normals. Però aquest és només un dels requisits previs RFP. Al final, a ningú li preocupa que cap venedor rus compleixi la condició de la interfície 32 * 100GE. O està preocupat?

Component 8. CI/CD

En aquest punt, ja tenim la configuració preparada per a tots els dispositius de xarxa.
Escric "per a tot" perquè estem parlant de versionar l'estat de la xarxa. I fins i tot si necessiteu canviar la configuració d'un sol commutador, els canvis es calculen per a tota la xarxa. Òbviament, poden ser zero per a la majoria de nodes.

Però, com ja s'ha dit més amunt, no som una mena de bàrbars que ho vulguin portar tot directament a la producció.
La configuració generada primer ha de passar per Pipeline CI/CD.

CI/CD són les sigles de Continuous Integration, Continuous Deployment. Aquest és un enfocament en el qual l'equip no només publica una nova versió principal cada sis mesos, substituint completament l'antic, sinó que implementa de manera incremental regularment noves funcionalitats (desplegament) en petites porcions, cadascuna de les quals es prova exhaustivament per a la compatibilitat, la seguretat i rendiment (integració).

Per fer-ho, disposem d'un sistema de control de versions que controla els canvis de configuració, d'un laboratori que verifica si el servei al client està trencat, d'un sistema de seguiment que verifica aquest fet, i l'últim pas és desplegar els canvis a la xarxa de producció.

Amb l'excepció de les ordres de depuració, absolutament tots els canvis a la xarxa han de passar pel pipeline CI/CD: aquesta és la nostra garantia d'una vida tranquil·la i una carrera llarga i feliç.

Component 9. Còpia de seguretat i sistema de detecció d'anomalies

Bé, no cal tornar a parlar de còpies de seguretat.
Simplement els posarem a git segons la corona o el fet d'un canvi de configuració.

Però la segona part és més interessant: algú hauria de vigilar aquestes còpies de seguretat. I en alguns casos, aquest algú ha d'anar i donar-li la volta a tot com era, i en d'altres, miaular a algú que alguna cosa no va bé.
Per exemple, si ha aparegut un usuari nou que no està registrat a les variables, l'heu d'eliminar del pirateig. I si és millor no tocar una nova regla del tallafoc, potser algú acaba d'activar la depuració, o potser el nou servei, un bangler, no estava registrat segons la normativa, però la gent ja s'hi ha incorporat.

Encara no ens escaparem d'algun petit delta a l'escala de tota la xarxa, malgrat els sistemes d'automatització i la mà d'acer de la gestió. Per depurar problemes, ningú afegirà configuració als sistemes de totes maneres. A més, és possible que ni tan sols s'incloguin al model de configuració.

Per exemple, una regla de tallafoc per comptar el nombre de paquets per IP específica per localitzar un problema és una configuració temporal completament normal.

Component 10. Sistema de seguiment

Al principi no anava a tractar el tema del seguiment, encara és un tema voluminós, polèmic i complex. Però a mesura que avançaven les coses, va resultar que això era una part integral de l'automatització. I és impossible evitar-ho, fins i tot sense pràctica.

Evolving Thought és una part orgànica del procés CI/CD. Després de desplegar la configuració a la xarxa, hem de poder determinar si tot està bé ara.
I estem parlant no només i no tant dels horaris d'ús de la interfície o de la disponibilitat de nodes, sinó de coses més subtils: la presència de les rutes necessàries, els atributs en elles, el nombre de sessions BGP, els veïns OSPF, el rendiment d'extrem a extrem. dels serveis superiors.
Els syslogs al servidor extern van deixar de sumar-se, o es va trencar l'agent SFlow, o les caigudes a les cues van començar a créixer, o es va trencar la connectivitat entre algun parell de prefixos?

Reflexionarem sobre això en un article a part.

Conclusió

Com a base, vaig triar un dels dissenys moderns de xarxa del centre de dades: L3 Clos Fabric amb BGP com a protocol d'encaminament.
Aquesta vegada construirem la xarxa a Juniper, perquè ara la interfície de JunOs és un vanlove.

Fem-nos la vida més difícil utilitzant només eines de codi obert i una xarxa de diversos proveïdors; així que, a més de Juniper, triaré una persona més afortunat pel camí.

El pla per a les properes publicacions és una cosa així:
Primer parlaré de les xarxes virtuals. En primer lloc, perquè vull, i en segon lloc, perquè sense això, el disseny de la xarxa d'infraestructures no quedarà molt clar.
A continuació, sobre el propi disseny de la xarxa: topologia, encaminament, polítiques.
Muntem un estand de laboratori.
Pensem-hi i potser practiquem inicialitzar el dispositiu a la xarxa.
I després sobre cada component amb un detall íntim.

I sí, no prometo acabar amb gràcia aquest cicle amb una solució ja feta. 🙂

links útils

• Abans d'aprofundir en la sèrie, val la pena llegir el llibre de Natasha Samoilenko Python per a enginyers de xarxa. I potser passar curs.
• També serà útil llegir RFC sobre el disseny de fàbriques de centres de dades de Facebook per Peter Lapukhov.
• La documentació d'arquitectura us donarà una idea de com funciona Overlay SDN. Teixit de tungstè (abans Open Contrail).

Gràcies

Congost Romà. Per comentaris i edicions.
Artyom Chernobay. Per a KDPV.

Font: www.habr.com