9. La Xarxa#

L’automatització de VLANs feia tres setmanes que s’executava al laboratori. Tres switches, un de cada proveïdor, cada flux de treball passant. L’equip se sentia confiat. A la primera execució en producció, 23 dels 800 switches de campus van fallar. Tots HPE. Tots executant una versió de firmware que ningú havia documentat.

El playbook estava comprovant la resposta d’error de cada dispositiu després d’enviar la configuració de VLAN. En el firmware HPE modern, una VLAN que ja existia retornava el codi d’error duplicate-vlan. En aquesta versió de firmware més antiga, la mateixa condició retornava vlan-exists. El playbook havia estat escrit per tractar duplicate-vlan com a senyal d’idempotència, és a dir, “això ja existeix, tot bé.” No havia estat escrit per gestionar vlan-exists, de manera que tractava aquella resposta com una fallada. Un terç de la flota HPE va informar de fallada. El rollback va executar-se sense problemes. El tiquet de l’equip d’aplicacions va romandre obert durant tres hores més mentre l’equip de xarxa auditava manualment quins switches havien estat configurats realment i quins no.

L’automatització no era errònia. La xarxa tenia una opinió que ningú havia documentat.

Sis mesos més tard, el mateix equip tenia una topologia de containerlab que reflectia l’Edifici B: 24 switches, imatges de proveïdor coincidents, amb els nodes HPE fixats a la versió de firmware de producció registrada a la Source of Truth (SoT). A la primera execució de prova del flux de treball de VLAN contra aquella topologia, 8 nodes HPE van fallar amb exactament aquell codi d’error. L’equip va afegir vlan-exists a la llista de respostes idempotents a l’adaptador HPE. Segona execució: tots els 24 nodes van passar. Desplegament en producció: 800 switches, zero fallades.

La diferència no era un millor codi. Era un entorn de prova que representava la realitat.

Aquest capítol aborda el bloc que havia estat sempre implícit al llarg de la Part 2: la pròpia xarxa. Cada bloc constructiu construït fins ara havia estat dissenyat per l’equip d’automatització i es comporta d’acord amb les seves interfícies documentades. La xarxa s’ha heretat. Té peculiaritats, interfícies diverses, inconsistències de firmware i capacitats que varien per proveïdor, plataforma i generació de programari. El Capítol 9 aborda dues preguntes: qué necessitem de la xarxa per fer l’automatització fiable, i com validem la lògica d’automatització de manera segura abans que toqui la producció?

9.1. Fonaments#

9.1.1. Context#

El Capítol 3 va introduir La Xarxa com un dels set blocs del NAF Framework: l’únic bloc que l’equip d’automatització no “posseeix” (és en l’àmbit de l’enginyeria de xarxa). La configuren, l’observen i en modelen la intenció, però no han construït el sistema operatiu, el model de dades ni la interfície de l’API. Aquesta dependència conforma cada decisió de disseny a la plataforma que hi ha al damunt.

El Capítol 5 va cobrir en detall el camí d’escriptura de l’Executor: com funcionen els rols d’automatització, les tasques parametritzades i les comprovacions d’idempotència. El que el Capítol 5 tracta com a donat és que el dispositiu de l’altre extrem exposa una interfície fiable i consistent. El Capítol 9 aborda si aquesta suposició es manté, i qué fer quan no ho fa.

El Capítol 6 va cobrir el camí de lectura del Collector: streaming de telemetria gRPC Network Management Interface (gNMI), polling SNMP i la pipeline de normalització de dades. El Capítol 9 cobreix els requisits previs del costat del dispositiu per a aquells camins: qué ha de ser cert sobre el dispositiu de xarxa perquè el collector pugui llegir d’ell de manera consistent.

El Capítol 9 tanca la Part 2. Els sis capítols anteriors han construït la plataforma d’automatització: un lloc per emmagatzemar la intenció, una manera d’executar-la, una manera d’observar els resultats, un motor per coordinar-ho tot i superfícies per exposar-lo als consumidors. Aquest capítol aborda la cosa a la qual la plataforma sempre apuntava.

9.1.2. Objectius#

Tres objectius defineixen la contribució del bloc La Xarxa a la plataforma d’automatització:

1. Entendre i navegar per l’espectre complet de la infraestructura de xarxa. Qualsevol plataforma d’automatització a gran escala pot parlar simultàniament amb switches de campus, fabrics de centre de dades, VPCs cloud, overlays de Kubernetes, controladors d’overlay i equipament llegat. Cada tipus exposa interfícies programables diferents. La plataforma ha de gestionar-les totes sense col·lapsar en una única abstracció del mínim comú denominador.

2. Validar la lògica d’automatització i donar suport al disseny de nova arquitectura de xarxa abans de tocar la producció. Els entorns de simulació serveixen dos propòsits: són la porta pre-producció on els errors de lògica, les violacions del contracte d’interfície i les peculiaritats específiques del dispositiu es capturen al cost de minuts en un laboratori en lloc d’hores en un incident de producció, i són l’entorn de disseny on s’exploren i validen noves arquitectures de xarxa abans de demanar cap maquinari.

3. Mantenir la plataforma d’automatització estable a mesura que la xarxa evoluciona. S’afegeixen nous proveïdors. Les versions de firmware canvien. Arriben nous tipus d’infraestructura. La plataforma ha de ser dissenyada per absorbir aquest canvi a través d’estratègies d’abstracció, no a través de pedaços ad hoc a cada flux de treball cada cop que la xarxa canvia.

9.1.3. Pilars#

Tres pilars suporten aquests objectius, un per funcionalitat:

1. Espectre d’infraestructura de xarxa i interfícies programables: la gamma completa de tipus de xarxa que la plataforma ha d’automatitzar, i la interfície que cada tipus exposa a l’Executor i al Collector.
2. Entorns de simulació i proves: el conjunt d’eines per a la validació pre-producció. On encaixen els diferents tipus d’entorn de laboratori, com es connecten al patró Saga del Capítol 7 i com escalar-los.
3. Estratègies d’abstracció: enfocaments estructurals que permeten a la plataforma d’automatització romandre estable a mesura que la xarxa subjacent canvia, independentment del proveïdor, la generació de plataforma o el protocol d’interfície.

9.1.4. Abast#

Dins de l’abast:

• Les interfícies a través de les quals l’Executor i el Collector arriben als dispositius de xarxa. Tant NETCONF com gNMI suporten operacions de configuració i telemetria; l’elecció entre ells per cas d’ús depèn de les fortaleses operatives, no de l’exclusivitat del protocol. El protocol sovint és compartit entre blocs; el tipus d’operació difereix.
• Els entorns de prova i les metodologies que validen l’automatització abans de la producció
• Estratègies d’abstracció per gestionar l’heterogeneïtat multiproveïdor i multiplataforma
• Les implicacions del cloud, Kubernetes i les xarxes overlay per al disseny de l’automatització

Fora de l’abast:

• Generació de configuració i renderització de plantilles (Source of Truth (SoT), Capítol 4)
• Mecànica d’execució: com les eines d’automatització executen una tasca (Executor, Capítol 5)
• La pipeline de recollida de telemetria: com les mètriques flueixen cap a la base de dades de sèries temporals (Observability, Capítol 6)

El límit és consistent: el Capítol 9 cobreix el costat de la xarxa de cada interfície, no el costat de la plataforma.

9.2. Funcionalitats#

El bloc La Xarxa és l’únic bloc constructiu del marc NAF que la plataforma d’automatització no controla. Només pot interactuar amb la xarxa tal com la xarxa ho permet. Cada decisió de disseny dels cinc capítols anteriors, com s’emmagatzema la intenció, com s’executa, com es recull la telemetria, com es coordinen els fluxos de treball, com es serveixen els consumidors, es resol en última instància en una pregunta sobre el que suporta el dispositiu de xarxa a l’altre extrem de la connexió. Aquest capítol examina directament aquesta restricció.

graph LR

    subgraph Goals["Objectius"]
        direction TB
        A1[Navegar per l'espectre complet de la infraestructura de xarxa]
        A2[Validar l'automatització abans de producció]
        A3[Mantenir la plataforma estable a mesura que la xarxa evoluciona]
    end

    subgraph Pillars["Pilars"]
        direction TB
        B1[Espectre d'infraestructura de xarxa i interfícies programables]
        B2[Entorns de simulació i proves]
        B3[Estratègies d'abstracció]
    end

    subgraph Functionalities["Funcionalitats"]
        direction TB
        C1[Interfícies Programables]
        C2[Entorns de Simulació i Proves]
        C3[Estratègies d'Abstracció]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

9.2.1. Interfícies Programables#

La xarxa és heterogènia per naturalesa. No és una sola cosa. És un espectre de tipus d’infraestructura acumulats al llarg dels anys, sovint construïts en paral·lel per equips diferents (la propietat i els límits organitzatius s’exploren al Capítol 13), cadascun amb el seu propi model d’interfície, nivell d’abstracció i maduresa d’automatització. Una plataforma d’automatització moderna pot abastar switches de campus, fabrics de centre de dades, VPCs cloud, controladors d’overlay, clústers de Kubernetes, infraestructura WAN de proveïdors de serveis i plans d’encaminament gestionats per hyperscalers, simultàniament. La plataforma ha de gestionar-los tots. El tipus d’infraestructura determina quina interfície està disponible; la plataforma d’automatització s’adapta a aquesta realitat en lloc de mandatar una interfície uniforme.

9.2.1.1. L’espectre de la infraestructura de xarxa#

Aquest és un resum d’alt nivell dels diferents escenaris d’infraestructura de xarxa que podeu haver d’abordar, depenent de la naturalesa de la vostra empresa:

• Switching de campus i oficines remotes és l’escenari principal que he usat com a exemple al llarg de la Part 2: switches físics multiproveïdor (Cisco, Arista, HPE, Extreme). Els equips de campus moderns exposen Command Line Interface (CLI), NETCONF i gRPC Network Management Interface (gNMI) simultàniament. La maduresa d’automatització és alta per als equips dels últims cinc a set anys; és irregular per als equips llegats que encara executen firmware de fa una dècada.

• Fabric de centre de dades la topologia és típicament leaf-spine, sovint d’un conjunt de proveïdors més petit: Arista, Cisco Nexus o plataformes de xarxa oberta natives d’automatització. La uniformitat d’interfície és major que al campus; la gestió de canvis és més estricta. Els overlays EVPN/VXLAN afegeixen un pla de gestió per sobre del fabric que pot tenir la seva pròpia API, separada de la interfície del dispositiu individual. Les plataformes basades en SONiC (Cisco 8000, Nvidia Spectrum) estan cada vegada més presents en els desplegaments de DC influïts pels hyperscalers; la seva interfície de configuració és una base de dades estructurada en lloc de CLI o NETCONF, i es cobreix més endavant a la secció d’estratègies d’abstracció.

• Infraestructura de proveïdor de serveis i WAN (routers de grau carrier, xarxes MPLS, fabrics de segment routing) té els seus propis reptes d’automatització: escala, complexitat de protocol i la doble preocupació de la configuració del pla de control i la política d’enginyeria de trànsit. NETCONF i els models YANG estan ben establerts en aquest espai; proveïdors com Cisco IOS-XR i Junos tenen una cobertura YANG madura. La plataforma d’automatització sovint apunta a un controlador (SR-PCE, Crosswork, NSO) en lloc de dispositius individuals.

• Xarxa cloud: AWS VPC, Azure VNet, GCP VPC i altres. APIs REST amb semàntiques de consistència eventual. No hi ha cap concepte d’“enviar una configuració” i esperar una confirmació síncrona. L’Executor gestiona les operacions asíncrones: crear, consultar, verificar. Les eines d’infraestructura com a codi s’adapten naturalment a aquest model. La plataforma d’automatització ha de tenir en compte el model de consistència diferent, no assumir semàntiques d’apply-i-confirmar síncrones.

• SD-WAN i xarxes overlay (Cisco SD-WAN, Versa, VMware VeloCloud) es gestionen per controlador. L’objectiu d’automatització és l’API del controlador, no el dispositiu individual. L’underlay físic segueix existint però es gestiona completament a través de l’abstracció de l’overlay. Això afecta tant l’execució com l’observabilitat: l’Executor escriu la política al controlador; la telemetria sobre el trànsit, la selecció de camins i l’aplicació de polítiques també flueix a través de la interfície nord del controlador, no directament dels dispositius d’underlay físics.

• Xarxa de Kubernetes a la capa CNI inverteix completament el model de dispositiu. La xarxa es defineix a través d’objectes de l’API de Kubernetes: NetworkPolicy, Services, Ingress i recursos personalitzats de plugins CNI com Cilium, Calico o Flannel. El dispositiu desapareix com a objectiu d’automatització. L’API de Kubernetes és la interfície. Les polítiques de xarxa són codi, no configuració de dispositiu. Aquest és el model cap al qual els altres convergeixen: intenció declarativa, estat reconciliat pel controlador, sense accés directe al dispositiu.

• DPUs i SmartNICs (Nvidia BlueField, Intel IPU, Marvell Octeon) representen un canvi en on es produeix el processament de xarxa. En els centres de dades moderns, les DPUs s’instal·len al costat de les CPUs a cada servidor per descarregar les funcions de xarxa: encapsulació VXLAN, xifratge, aplicació de polítiques de tallafocs, balanceig de càrrega i microsegmentació. Això descarrega aquestes funcions de la CPU de l’amfitrió i dels dispositius de xarxa dedicats al firmware de la SmartNIC. La conseqüència per a l’automatització: “el dispositiu de xarxa” ja no és únicament un switch o router al rack. Les funcions gestionades prèviament a través d’APIs de dispositius de xarxa dedicats ara es gestionen a través del pla de gestió de la DPU i el seu SDK del proveïdor, una nova categoria d’interfície a la qual les eines estàndard de NETCONF i gRPC Network Management Interface (gNMI) encara no arriben de manera neta.

• Xarxa oberta (SONiC, DENT, OPX) executa programari Network Operating System (NOS) en maquinari de commodity. La interfície de configuració de SONiC és una base de dades Redis amb un esquema estructurat per Yet Another Next Generation (YANG), estructuralment diferent de CLI o NETCONF, i programàtica per disseny. Cada vegada més present en centres de dades empresarials de gran escala influïts pels hyperscalers. SONiC és notable perquè va ser dissenyat per a l’automatització des del principi: la interfície és una base de dades estructurada, no una CLI adaptada per a l’accés programàtic.

• Funcions de xarxa virtuals coexisteixen amb la infraestructura física en molts entorns. Un tallafocs de programari que insereix trànsit a través de camins definits per política, un balançador de càrrega virtual que gestiona la distribució del trànsit entre els clústers d’aplicació, un reflector de rutes BGP basat en programari: tots aquests són objectius d’automatització que usen interfícies de gestió que van des d’APIs REST de proveïdor fins a NETCONF. Sovint es gestionen al costat de l’inventari físic usant el mateix SoT i Executor, però requereixen camins d’adaptador separats perquè els seus models d’interfície difereixen dels dispositius físics.

• Controladors sense fil (Cisco DNA, Aruba Central, Juniper Mist) es gestionen per controlador; l’objectiu d’automatització és l’API del controlador. Rellevant sempre que el provisió de VLANs s’estengui als SSIDs sense fil al costat dels ports de switch per cable, com seria al cas del campus.

El punt no és enumerar exhaustivament cada tipus d’infraestructura. És establir que una plataforma que automatitza qualsevol xarxa no trivial interactua amb múltiples tipus simultàniament. L’Executor i el Collector han d’enrutar cada operació al tipus d’interfície correcte. La Source of Truth (SoT) ha de modelar la intenció a un nivell per sobre de la interfície individual. La complexitat de la xarxa és la restricció de disseny que la plataforma va ser construïda per absorbir.

9.2.1.2. Tipus d’interfície#

Cada tipus d’infraestructura exposa un o més tipus d’interfície a la plataforma d’automatització. El mateix switch físic pot exposar els tres simultàniament. La plataforma s’adapta al que està disponible, amb preferències que reflecteixen la fiabilitat, l’estructura i l’escala. Cap tipus d’interfície és un mandat universal; l’elecció correcta depèn del que suporta el dispositiu i del que requereix l’operació.

• Command Line Interface (CLI) sobre Secure Shell (SSH) és universal, llegat i fràgil. El screen-scraping i l’anàlisi de text es trenca quan el firmware canvia el format de sortida o afegeix nous camps. Els codis d’error són inconsistents entre proveïdors i entre versions de firmware. La CLI segueix sent l’única opció per als equips més antics. La recomanació és minimitzar-ne l’ús i evitar construir fluxos de treball que en depenguin per a res més que els dispositius que no tenen alternativa (l’últim recurs). Establir una descripció d’interfície sembla:

interface GigabitEthernet0/1
 description uplink-to-core

• NETCONF és estructurat, transaccional i correcte quan funciona. Suporta operacions atòmiques i rollback, i el seu model de dades és analitzable per màquina. La capa de transport és generalment fiable; la capa del model de dades és on es troben les llacunes. La qualitat del model YANG del proveïdor varia significativament: un dispositiu pot afirmar suport NETCONF però tenir models incomplets o propietaris per a les funcions que necessita la plataforma. Els models YANG IETF i OpenConfig estandarditzen la capa d’intenció; els models YANG nadius del proveïdor omplen les llacunes. La mateixa descripció d’interfície via NETCONF:

<config>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet0/1</name>
      <description>uplink-to-core</description>
    </interface>
  </interfaces>
</config>

• RESTCONF és l’equivalent basat en HTTP de NETCONF, usant els mateixos models YANG però exposats sobre semàntiques REST. És útil quan els equips se senten més còmodes amb les eines HTTP que amb el transport XML/SSH de NETCONF. El model de dades és el mateix; només el transport difereix. El suport del proveïdor és menys uniforme que NETCONF. La mateixa descripció d’interfície via RESTCONF:

PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Content-Type: application/yang-data+json

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/1",
    "description": "uplink-to-core"
  }
}

• gRPC Network Management Interface (gNMI) i gNOI són protocols basats en gRPC Remote Procedure Call (gRPC). gRPC Network Management Interface (gNMI) gestiona la lectura/escriptura de telemetria i configuració; gNOI gestiona les comandes operatives. Modern i amigable amb l’escala. El suport del proveïdor és madur en Arista i les plataformes Cisco més noves; és irregular en HPE i els equips llegats. El Capítol 6 va cobrir gNMI des de la perspectiva del Collector. El Capítol 9 cobreix els requisits previs del costat del dispositiu: el dispositiu ha de suportar les subscripcions gNMI a la versió del SO que apunta la plataforma. El mateix SetRequest gNMI per a la descripció d’interfície:

path:  /interfaces/interface[name=GigabitEthernet0/1]/config/description
value: "uplink-to-core"

• APIs REST del proveïdor (eAPI, NX-API, Cumulus NVUE i similars) són llegibles per màquina però no estandarditzades entre proveïdors. Útils com a complement quan NETCONF o gNMI és absent o incomplet per a una operació específica. Tracteu-les com a preocupacions de la capa adaptadora, no com a base per a una plataforma neutral al proveïdor. La mateixa descripció d’interfície via eAPI d’Arista (JSON-RPC sobre HTTPS):

{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": [
      "interface GigabitEthernet0/1",
      "description uplink-to-core"
    ],
    "format": "json"
  },
  "id": "1"
}

• APIs cloud i de controlador segueixen patrons REST amb consistència eventual. El model d’operació asíncrona és un requisit de disseny, no una limitació que cal evitar. Per als plans de gestió d’SD-WAN, sense fil i DPU, l’API del controlador sovint és l’única interfície disponible. Afegir una descripció a un VPC d’AWS il·lustra el patró: una actualització de recurs etiquetada enviada de manera asíncrona, sense confirmació síncrona que el canvi s’ha aplicat:

POST https://ec2.eu-west-1.amazonaws.com/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded

Action=CreateTags
&ResourceId.1=vpc-0a1b2c3d4e5f67890
&Tag.1.Key=Description
&Tag.1.Value=uplink-to-core
&Version=2016-11-15

• L’API de Kubernetes és declarativa, reconciliada pel controlador i consistent entre proveïdors. NetworkPolicy, Services i els recursos personalitzats CNI són els objectius d’automatització. No hi ha accés directe al dispositiu; el servidor de l’API és la única interfície. Una política d’aïllament de xarxa per al servei app-payments:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-payments-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: app-payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-payments

• SONiC CONFIG_DB (Redis) és la interfície nativa per a les plataformes basades en SONiC. En lloc d’un protocol posat al damunt del SO, és el propi magatzem de configuració del SO: una base de dades Redis amb un esquema estructurat per YANG. L’automatització escriu entrades JSON directament a CONFIG_DB; el dimoni intern orchagent de SONiC reconcilia la intenció amb les taules d’encaminament del maquinari. gNMI està disponible en paral·lel per a les lectures de telemetria. Això és arquitectònicament diferent de CLI, NETCONF o REST: la interfície és el propi magatzem de dades. La mateixa descripció d’interfície escrita a CONFIG_DB via pedaç JSON:

{
  "PORT": {
    "Ethernet0": {
      "description": "uplink-to-core",
      "admin_status": "up"
    }
  }
}

9.2.1.3. Selecció d’interfície per dispositiu#

Quan un dispositiu exposa múltiples interfícies, la plataforma ha de triar-ne una per tipus d’operació i mantenir aquesta elecció de manera consistent. Un switch de campus que exposa Command Line Interface (CLI), NETCONF i gRPC Network Management Interface (gNMI) simultàniament requereix una decisió, no un enfocament barrejat que varia per flux de treball o preferència de l’enginyer.

Jerarquia recomanada, aplicada per tipus d’operació. Tant gRPC Network Management Interface (gNMI) com NETCONF suporten escriptures de configuració i lectures de telemetria; la preferència següent reflecteix les fortaleses operatives, no l’exclusivitat del protocol:

• gRPC Network Management Interface (gNMI) preferit per a la recollida de telemetria (subscripcions de streaming, estructurades, amigables amb l’escala; gNMI Set és també un camí de configuració vàlid)
• NETCONF preferit per a la configuració (transaccional, amb capacitat de rollback; NETCONF get i get-config són igualment vàlids per a les lectures d’estat)
• RESTCONF o API REST del proveïdor com a alternativa quan NETCONF és incomplet per a una funcionalitat específica
• Command Line Interface (CLI) com a últim recurs únicament per als equips llegats

El que l’Executor necessita de la interfície: Idempotency o almenys codis d’error fiables que distingeixin “ja existeix” de “ha fallat”, respostes d’error estructurades i capacitat de verificació d’estat després de l’apply. El problema HPE vlan-exists vs duplicate-vlan era precisament una fallada de la segona condició: la semàntica del codi d’error va canviar entre versions de firmware.

El que el Collector necessita: lectures estructurades, subscripcions de streaming de telemetria i models de dades consistents perquè la capa d’Observabilitat no necessiti analitzadors per dispositiu. gRPC Network Management Interface (gNMI) és el protocol de subscripció preferit on és suportat: és estructurat, jeràrquic i validat per esquema al dispositiu, cosa que elimina l’anàlisi de text per dispositiu que dominava la recollida de l’era SNMP. Però qualsevol mecanisme de subscripció que lliuri dades estructurades i oportunes compleix la mateixa funció.

La Source of Truth (SoT) registra l’estat previst per a cada atribut de dispositiu sobre el qual opera la plataforma: configuració de VLAN prevista, relacions de veïns BGP previstes, descripcions d’interfície previstes i versió del SO prevista. La versió del SO mereix una menció especial aquí perquè afecta no tan sols la detecció de deriva de configuració sinó la pròpia selecció del camí de l’adaptador: l’Executor bifurca per versió del SO quan el firmware del mateix proveïdor es comporta de manera diferent entre llançaments.

9.2.2. Entorns de Simulació i Proves#

La xarxa és infraestructura de producció. A diferència d’un backend d’aplicació, no hi ha cap servidor de proves per defecte contra el qual provar. Construir-ne un és la feina d’aquesta funcionalitat.

Provar l’automatització de xarxes sempre ha estat més difícil que provar el codi d’aplicació. Una xarxa és un sistema distribuït amb molts components que l’equip d’automatització no controla: ASes veïns en punts de peering, proveïdors de trànsit aigües amunt, CPE gestionat pel client, clients sense fil i infraestructura cloud operada per tercers. Els entorns de simulació descrits en aquesta secció són el millor substitut disponible: reprodueixen el que l’equip controla, accepten les limitacions del que no poden, i focalitzen la validació en la capa de lògica on realment viuen els errors.

La piràmide de proves del Capítol 2 (unitat, integració, extrem a extrem) s’aplica directament aquí. Les proves unitàries validen els mòduls d’automatització individuals de manera aïllada, típicament amb respostes de dispositiu simulades. Les proves d’integració validen les interaccions de múltiples passos. Les proves extrem a extrem validen el flux de treball complet contra alguna cosa que es comporta com un dispositiu de xarxa real. Els entorns de simulació són la capa extrem a extrem.

9.2.2.1. Tipus d’entorn#

L’entorn correcte depèn del que la prova necessita validar. Hi ha un espectre des d’entorns de baixa fidelitat i baix cost adequats per a les pipelines de CI/CD rutinàries, fins a entorns d’alta fidelitat que val la pena invertir-hi per a les proves de confiança en producció.

• L’emulació basada en contenidors usa imatges de SO de xarxa lleugeres que s’executen com a contenidors, connectades per enllaços virtuals. L’arrencada de la topologia triga segons. És el predeterminat pràctic per al CI/CD rutinari: l’equip d’automatització executa el mateix codi de flux de treball contra una topologia en contenidors en cada canvi, capturant errors de lògica abans de la producció. El comportament del pla de dades no es replica, però el comportament del pla de control i el de la interfície de gestió són suficients per provar la lògica d’automatització.

• L’emulació basada en VMs executa imatges completes del NOS com a màquines virtuals. Proporciona una cobertura de proveïdors més àmplia, un comportament del NOS més realista incloent el pla de dades, i és adequada per a les proves de disseny de protocols i escenaris d’interoperabilitat multiproveïdor. El compromís: major cost de recursos, arrencada més lenta i integració limitada amb les pipelines automatitzades.

• Els laboratoris de maquinari físic els mantenen moltes organitzacions grans: un rack de switches i routers reals, sovint reflectint els patrons de l’arquitectura de producció. Proporciona la màxima fidelitat per als comportaments específics del maquinari, les proves de rendiment i els escenaris on l’emulació no reprodueix amb precisió el comportament del dispositiu. El cost és significatiu: inversió de capital, energia i espai, i la sobrecàrrega operativa de mantenir la topologia del laboratori sincronitzada amb l’arquitectura de producció.

• Els bessons digitals són rèpliques en viu de la topologia de producció, alimentades per la Font de Veritat (els mateixos models de dispositiu, topologia i configuració prevista actual) i l’estat actual de l’Observabilitat. Un bessó digital reflecteix com és realment la producció ara mateix, no una aproximació. El cost operatiu és significatiu: mantenir la sincronització entre el bessó digital i la producció requereix una reconciliació contínua. És una inversió de nivell de maduresa, adequada per als equips que ja han validat la seva plataforma a escala i necessiten el màxim nivell de confiança pre-producció.

9.2.2.2. Conjunt d’eines per a l’emulació basada en contenidors i VMs#

L’ecosistema basat en contenidors té diverses eines amb rols diferenciats que sovint es confonen:

• containerlab instancia i connecta imatges de SO de xarxa basades en contenidors. Creat per Roman Dodin i àmpliament adoptat a tota la comunitat d’automatització de xarxes, containerlab s’ha convertit en l’estàndard de facto per als laboratoris de xarxa basats en contenidors. Orquestra directament contenidors Docker (Arista cEOS, FRR, SONiC, VyOS i altres) i els connecta amb enllaços virtuals definits en un fitxer de topologia. containerlab inicia la topologia i proporciona un laboratori en execució en qüestió de segons. Un fitxer de topologia mínim de tres nodes té aquest aspecte:

  A mesura que els equips escalen, executar containerlab en una sola màquina es converteix en un coll d’ampolla. clabernetes distribueix les topologies de containerlab entre un clúster de Kubernetes, permetent múltiples execucions de simulació en paral·lel i permetent als equips escalar la seva porta pre-producció a mesura que la plataforma creix.

name: building-b-sim
topology:
  nodes:
    cisco-1:
      kind: ceos
      image: ceos:17.9.4
    arista-1:
      kind: ceos
      image: ceos:4.31.2F
    hpe-1:
      kind: vr-aoscx
      image: vrnetlab/vr-aoscx:10.12.1006
  links:
    - endpoints: ["cisco-1:eth1", "arista-1:eth1"]
    - endpoints: ["arista-1:eth2", "hpe-1:eth1"]

• netlab abstrau la definició de topologia per damunt de containerlab. Creat per Ivan Pepelnjak, netlab permet a l’enginyer descriure el que la topologia hauria d’aconseguir en lloc de com connectar-la: “aquests tres nodes executen BGP”, “aquests nodes estan a la mateixa VLAN”. netlab interpreta aquella descripció i la renderitza en un fitxer de topologia de containerlab més les configuracions inicials dels dispositius per proveïdor. Penseu-hi com una descripció declarativa del laboratori. Un fitxer de topologia netlab mínim per al mateix escenari de tres nodes:

nodes:
  cisco-1:
    device: iosxe
    image: ceos:17.9.4
  arista-1:
    device: eos
  hpe-1:
    device: aoscx

links:
  - cisco-1:
    arista-1:
  - arista-1:
    hpe-1:

vlans:
  app-payments:
    id: 210
    links: [ cisco-1, arista-1, hpe-1 ]

• vrnetlab fa de pont entre l’emulació basada en contenidors i la basada en VMs. Alguns proveïdors no proporcionen imatges de contenidors natives. vrnetlab embolcalla les imatges de VM del proveïdor dins de contenidors, fent-les usables dins d’una topologia de containerlab.

• EVE-NG i GNS3 són plataformes d’emulació basades en VMs que proporcionen una àmplia cobertura de proveïdors, disseny de topologia basat en GUI i un comportament complet del NOS incloent l’encaminament del pla de dades. El compromís: major ús de recursos, arrencada més lenta i integració limitada amb el CI/CD. Aquestes són l’elecció correcta per a les proves de protocols i disseny, plataformes llegades i escenaris d’interoperabilitat multiproveïdor.

• Cisco Modeling Labs és la plataforma comercial de laboratori VM de Cisco amb una API REST per a la integració parcial amb CI/CD. L’elecció correcta per als entorns centrats en Cisco que necessiten accés a VMs IOS-XE, IOS-XR i NX-OS en un laboratori compartit i gestionat.

9.2.2.3. Marcs de validació#

Validar que un dispositiu suporta correctament un protocol d’interfície determinat o un camí YANG forma part del treball descrit al Capítol 5 (Execució) i al Capítol 6 (Observabilitat).

Un escenari mereix un tractament específic en el context de la simulació: la validació per onades. Després que la simulació passa però abans de comprometre’s amb tot l’abast de producció, alguns equips executen una passada de validació estructurada contra la primera onada. pyATS proporciona un marc de proves per escriure proves d’interacció de dispositius estructurades amb anàlisi ric i comparació d’estat. Robot Framework és un marc d’automatització de proves més ampli basat en paraules clau amb biblioteques específiques de xarxa. Tots dos permeten a un equip codificar l’estat post-canvi esperat com a afirmacions executables.

Una prova pyATS mínima que afirma la presència de VLAN després del desplegament:

from pyats import aetest

class VlanValidation(aetest.Testcase):
    @aetest.test
    def verify_vlan_exists(self, device):
        output = device.parse('show vlan brief')
        assert 210 in output['vlans'], f"VLAN 210 missing on {device.name}"

    @aetest.test
    def verify_vlan_name(self, device):
        output = device.parse('show vlan brief')
        assert output['vlans'][210]['name'] == 'app-payments'

La mateixa comprovació a Robot Framework usant la biblioteca NAPALM:

*** Settings ***
Library    Collections
Library    napalm    WITH NAME    NAPALM

*** Variables ***
@{DEVICES}    cisco-1    arista-1    hpe-1

*** Test Cases ***
VLAN 210 Is Present On All Switches After Deployment
    FOR    ${hostname}    IN    @{DEVICES}
        Connect And Check VLAN    ${hostname}    210    app-payments
    END

*** Keywords ***
Connect And Check VLAN
    [Arguments]    ${hostname}    ${vlan_id}    ${vlan_name}
    NAPALM.Open    ${hostname}
    ${vlans}=    NAPALM.Get VLANs
    Dictionary Should Contain Key    ${vlans}    ${vlan_id}
    Should Be Equal    ${vlans}[${vlan_id}][name]    ${vlan_name}
    [Teardown]    NAPALM.Close

9.2.2.4. La simulació com a porta Saga pre-producció#

El Capítol 7 va descriure el patró Saga: un flux de treball de múltiples passos on cada pas té una acció compensatòria corresponent que s’executa si un pas posterior falla. La Saga gestiona les fallades en producció. La simulació afegeix el pas abans que la Saga comenci: executeu el flux de treball contra un entorn de simulació primer. Si l’execució de simulació falla, no es produeix cap canvi en producció. Només quan la simulació passa el flux de treball procedeix cap a l’objectiu de producció.

flowchart LR
    SoT["Exportació del SoT (topologia + versions SO)"]
    Lab["Entorn de simulació (topologia containerlab)"]
    Workflow["Execució del flux de treball (mateix codi que producció)"]
    Pass{Passa?}
    Prod["Execució en producció (Orquestrador: abast complet)"]
    Fix["Investigar i corregir (sense impacte en producció)"]

    SoT --> Lab --> Workflow --> Pass
    Pass -- Sí --> Prod
    Pass -- No --> Fix --> Workflow

Implementació pràctica:

1. La Font de Veritat exporta la definició de topologia per a l’abast objectiu, incloent les versions del SO per dispositiu.
2. L’entorn de simulació s’instancia amb imatges de proveïdor coincidents, amb les versions del SO fixades per coincidir amb l’estat previst del SoT.
3. El mateix flux de treball que s’executarà en producció s’executa primer contra l’objectiu de simulació.
4. Qualsevol pas que falli en simulació desencadena la investigació abans de procedir amb l’execució en producció.

Onades de desplegament progressiu

Passar la simulació no significa desplegar a tot l’abast de producció alhora. Per als llançaments a gran escala, la simulació és la primera porta d’una sèrie d’onades progressivament més grans, cadascuna amb la seva pròpia comprovació de validació abans que procedeixi la propera onada. Aquest és un dels meus patrons preferits per guanyar confiança amb els desplegaments crítics, similar al popular patró Canari del desenvolupament de programari.

Un equip que desplega un nou flux de treball a 100 centres de dades podria estructurar-ho com: simulació (topologia virtual) -> 1 lloc pilot -> 2 llocs -> 4 -> 8 -> 16 -> llocs restants. Cada onada valida que el flux de treball s’ha comportat correctament a l’onada anterior abans d’expandir-se.

flowchart LR
    Sim["Simulació"] --> W1["Onada 1 (1 lloc)"] --> W2["Onada 2 (2 llocs)"] --> W3["Onada 3 (4 llocs)"] --> W4["Onada N (abast complet)"]
    W1 -- Fallada --> Fix["Investigar + corregir"]
    W2 -- Fallada --> Fix
    W3 -- Fallada --> Fix
    Fix --> Sim

L’Orquestrador controla la progressió de les onades. El SoT delimita cada onada per lloc, edifici o grup de dispositius. Les portes de validació entre onades són passos explícits del flux de treball: l’Orquestrador comprova la capa d’Observabilitat per a l’estat esperat abans de continuar. Aquest patró s’aplica tant si l’abast és 100 centres de dades com 800 switches de campus: el principi és limitar el radi d’impacte de qualsevol fallada imprevista mentre es construeix confiança amb cada onada reeixida.

Limitacions de la simulació: les imatges de contenidors no reprodueixen tots els comportaments del firmware. Unaimage de contenidor típicament executa codi del NOS recent; les peculiaritats específiques de firmware antic poden no ser reproduïbles a menys que la imatge estigui fixada a una versió específica. La simulació captura errors de lògica, violacions de contractes d’interfície, llacunes del model YANG i fallades a nivell de topologia. No garanteix que s’hagi provat cada possible estat del dispositiu que s’encontrarà en producció. L’objectiu és una reducció significativa del risc, no el risc zero.

9.2.3. Estratègies d’Abstracció#

La xarxa és heterogènia per naturalesa, i no tan sols en el sentit que els proveïdors difereixen. Qualsevol plataforma d’automatització que opera a escala abasta simultàniament switching físic, infraestructura cloud, controladors d’overlay, infraestructura WAN de proveïdors de serveis i equips llegats. Cadascun parla un idioma diferent. La plataforma d’automatització no s’ha de reconstruir cada vegada que s’afegeix un nou tipus d’infraestructura.

Aquesta secció tracta de dissenyar la capa d’automatització per absorbir el canvi en lloc de trencar-se sota el seu pes: no tan sols gestionar l’heterogeneïtat actual sinó dissenyar per als tipus d’infraestructura que s’afegiran l’any vinent.

flowchart LR
    SoT["Font de Veritat"]
    Orch["Orquestrador"]
    Obs["Observabilitat"]

    subgraph Physical["Domini físic"]
        PhysIF["Interfície de xarxa (NETCONF/gNMI)"]
        PhysNet["Campus, fabric DC, equip WAN"]
        PhysIF --- PhysNet
    end

    subgraph Cloud["Domini cloud"]
        CloudIF["Interfície de xarxa (REST asíncron)"]
        CloudNet["VPCs cloud / xarxa cloud"]
        CloudIF --- CloudNet
    end

    subgraph Overlay["Domini overlay"]
        OvIF["Interfície de xarxa (API del controlador)"]
        OvNet["SD-WAN / MPLS PCE / overlay"]
        OvIF --- OvNet
    end

    SoT --> Orch
    Orch -->|Escriptura Executor| PhysIF
    Orch -->|Escriptura Executor| CloudIF
    Orch -->|Escriptura Executor| OvIF
    PhysIF -->|Lectura Collector| Obs
    CloudIF -->|Lectura Collector| Obs
    OvIF -->|Lectura Collector| Obs

La Font de Veritat modela la intenció completa entre tots els tipus de topologia com un model de servei unificat. L’Orchestrator conté branques per domini de xarxa. L’Executor enruta a l’adaptador correcte basant-se en les dades del SoT. L’Observabilitat abasta totes les capes, alimentant la mateixa pipeline de dades independentment del tipus d’infraestructura subjacent.

La disciplina arquitectònica clau: la bifurcació passa a l’Executor i l’Orquestrador, no al SoT. El SoT conté un únic model d’intenció per al servei. Com aquella intenció es realitza en tipus d’infraestructura diferents és una preocupació de l’Executor.

9.2.3.1. Dimensions de l’heterogeneïtat#

Abans de triar una estratègia d’abstracció, ajuda entendre l’eix d’heterogeneïtat que aquella estratègia ha d’absorbir. No tota l’heterogeneïtat és el mateix tipus de problema.

9.2.3.2. Patró adaptador a l’Executor i el Collector#

El punt de partida més comú i l’estratègia més àmpliament implementada. Un mòdul d’automatització per proveïdor, tots acceptant la mateixa estructura de dades d’entrada del SoT. El SoT emmagatzema la intenció neutral al proveïdor; la capa adaptadora de l’Executor la tradueix per proveïdor en el moment de l’execució. El mateix principi s’aplica al Collector: un mòdul de recollida per proveïdor o protocol, tots lliurant una estructura de dades normalitzada a la pipeline d’Observabilitat.

flowchart LR
    SoT["Intenció del SoT (neutral al proveïdor): vlan_id=210, vlan_name=app-payments"]
    Exec["Executor"]
    CiscoA["Adaptador Cisco: IOS-XE NETCONF"]
    AristaA["Adaptador Arista: eAPI / EOS"]
    HPEA["Adaptador HPE: NETCONF + gestió errors versió SO"]
    CiscoD["Cisco Catalyst"]
    AristaD["Arista 7050"]
    HPED["HPE Aruba 6300"]

    CollGNMI["Collector: adaptador gNMI"]
    CollSNMP["Collector: adaptador SNMP"]
    Obs["Pipeline d'Observabilitat (esquema normalitzat)"]

    SoT --> Exec
    Exec --> CiscoA --> CiscoD
    Exec --> AristaA --> AristaD
    Exec --> HPEA --> HPED

    CiscoD --> CollGNMI --> Obs
    AristaD --> CollGNMI
    HPED --> CollSNMP --> Obs

Pràctic de construir i ben comprès. La càrrega de manteniment creix a mesura que l’inventari de dispositius es diversifica: cada nou proveïdor o versió del SO requereix un adaptador nou o actualitzat. El patró adaptador escala bé per a un conjunt definit de proveïdors; es torna onerós quan la plataforma ha de suportar un catàleg de dispositius gran i que canvia freqüentment.

9.2.3.3. Models YANG impulsats per la comunitat i la indústria#

Dos organismes de la indústria publiquen els models YANG neutrals al proveïdor que redueixen el treball per adaptador. Els models IETF (publicats com a RFCs i Internet-Drafts) defineixen estructures de dades fundacionals: ietf-interfaces, ietf-routing, ietf-bgp. Els models OpenConfig, desenvolupats per un consorci d’operadors (Google, AT&T, Deutsche Telekom i altres), cobreixen un terreny similar amb un esquema més orientat a les operacions i un cicle d’iteració més ràpid. Tots dos permeten a la plataforma d’automatització escriure la intenció una vegada contra un model estàndard i esperar que funcioni en qualsevol dispositiu compliant.

Un mòdul YANG que defineix una interfície té aquest aspecte (simplificat de ietf-interfaces):

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name      { type string; }
      leaf description { type string; }
      leaf enabled   { type boolean; default true; }
    }
  }
}

La realitat pràctica d’OpenConfig: les implementacions dels proveïdors varien en completesa. Un dispositiu pot afirmar suport d’OpenConfig però implementar-ne únicament un subconjunt: les lectures funcionen, les escriptures no; o el model d’interfície funciona però el model BGP és absent.

Més enllà dels camins absents, el problema més insidiós és la inconsistència de les dades. Un dispositiu retorna un valor per a un camí OpenConfig però en la unitat incorrecta, amb un tipus diferent o amb camps que haurien de ser null emplenats amb valors predeterminats específics del proveïdor. Aquests no són casos límit rars. Planifiqueu les proves per dispositiu abans de confiar en un nou camí OpenConfig a l’automatització de producció.

Una nota sobre les famílies de models YANG

Tres famílies de models Yet Another Next Generation (YANG) coexisteixen en les xarxes de producció:

• Models IETF es desenvolupen a través del procés d’estàndards IETF i es publiquen com a RFCs o Internet-Drafts. Són els estàndards fundacionals: ietf-interfaces, ietf-routing, ietf-bgp. L’adopció és àmplia però lenta.
• Models OpenConfig es desenvolupen pel consorci OpenConfig, un grup impulsat per operadors. OpenConfig itera més ràpid que l’IETF i està més orientat a les operacions. La majoria dels desplegaments gNMI en producció usen camins OpenConfig.
• Models nadius del proveïdor són les extensions pròpies de cada proveïdor: cisco-ios-xe-native, junos-conf-root, arista-eos-augments. Exposen funcions que els models estàndard no cobreixen, i sovint són necessaris per a res més que les funcions del mínim comú denominador que aborden IETF i OpenConfig.

9.2.3.4. SONiC i la xarxa oberta#

La interfície de configuració de SONiC és una base de dades Redis amb un esquema estructurat per YANG: uniforme, programàtica i dissenyada per a l’automatització des del principi. El treball d’adaptador específic del proveïdor que consumeix esforç en els entorns físics multiproveïdor no s’aplica aquí. La mateixa lògica d’automatització funciona en totes les plataformes basades en SONiC independentment del proveïdor del maquinari subjacent.

Una entrada de VLAN al CONFIG_DB de SONiC:

{
  "VLAN": {
    "Vlan210": {
      "vlanid": "210"
    }
  },
  "VLAN_MEMBER": {
    "Vlan210|Ethernet0": {
      "tagging_mode": "untagged"
    }
  }
}

Aquest JSON s’escriu directament a Redis via sonic-cfggen o l’API REST de gestió de SONiC. No hi ha CLI a analitzar, ni XML a construir. La plataforma d’automatització escriu dades estructurades; l’orchagent de SONiC les reconcilia amb les taules d’encaminament del maquinari.

Aquesta és la direcció de disseny que advoca la xarxa oberta: una interfície de xarxa dissenyada per a l’automatització en lloc d’adaptada a ella. Els equips que introdueixin plataformes basades en SONiC al costat dels equips tradicionals trobaran que l’adaptador SONiC és el més simple d’escriure i el més fiable d’operar.

9.2.3.5. Gestió de la coexistència durant la migració de firmware#

El patró adaptador assumeix una versió del SO coneguda i estable per dispositiu. Durant una actualització de firmware progressiva, aquella suposició es trenca: els dispositius del mateix rol, gestionats per la mateixa plataforma d’automatització, executen versions del SO diferents simultàniament durant dies o setmanes.

El SoT hauria de registrar la versió del SO prevista (l’objectiu després de la migració) i el Collector hauria de presentar la versió del SO actual com a estat operatiu. Abans que l’Executor apliqui la configuració, hauria de llegir la versió actual del SO del Collector o la pipeline d’Observabilitat i seleccionar el camí d’adaptador adequat, no assumir que la versió prevista ja s’ha desplegat.

Un mecanisme concret: l’Executor consulta el bloc d’Observabilitat (o una comprovació pre-execució lleugera contra el propi dispositiu) per a la versió del SO en execució. El registre d’adaptadors associa els rangs de versions del SO a les implementacions dels adaptadors. L’Executor invoca l’adaptador correcte basant-se en l’estat actual, no en la intenció del SoT. Un cop actualitzat un dispositiu i la versió en execució coincideixi amb la intenció, la selecció de l’adaptador s’estabilitza. Durant la finestra de migració, dos camins d’adaptador per al mateix proveïdor poden estar actius simultàniament.

La implicació organitzativa: algú ha de posseir el seguiment de la versió del SO al SoT, el registre de versions de l’adaptador i el flux de treball de seqüenciació de l’actualització. Aquests tres artefactes formen el sistema d’automatització de l’actualització. Sense una propietat explícita, evolucionen de manera independent i la fiabilitat de la plataforma es degrada amb cada llançament de firmware.

9.2.4. La Xarxa com a Restricció de Cada Bloc#

Les tres àrees cobertes en aquesta secció, interfícies programables, entorns de simulació i estratègies d’abstracció, no són temes aïllats. Descriuen la influència de la xarxa en cada bloc del marc NAF.

Les capacitats d’interfície de la xarxa restringeixen el que l’Executor pot fer: un dispositiu que només suporta CLI força l’adaptador de l’Executor cap al fràgil screen scraping; un dispositiu amb suport gNMI madur permet la configuració fiable i la telemetria en streaming. El suport de recollida de la xarxa restringeix el que el Collector pot ingestar. La topologia de la xarxa restringeix el que l’Orquestrador pot paral·lelitzar de manera segura: una mida de lot que és segura per a una capa d’accés plana pot ser catastròfica per a un fabric spine-leaf on els canvis simultanis a múltiples nodes spine poden partir la xarxa.

El model de dades del SoT reflecteix aquestes restriccions. Els camps de versió del SO activen la selecció de l’adaptador. Els camps de tipus d’interfície activen el mètode de recollida. Les relacions de topologia activen les regles de concurrència de l’Orquestrador. Un SoT que registra l’inventari de dispositius sense registrar els atributs rellevants per a l’automatització (capacitats de la interfície, versió del SO, rol de la topologia) és incomplet de maneres que només es revelen en el moment de l’execució.

9.3. Exemple d’Implementació#

9.3.1. De la Simulació a la Producció#

El flux de treball de VLAN del campus està llest. Vuit setmanes de desenvolupament, tres proveïdors modelats, idempotència provada contra un laboratori de tres nodes. L’equip vol desplegar-lo a producció: 800 switches, edificis A a F. Abans que això passi, l’executen contra la simulació.

Aquest exemple segueix la seqüència de la porta pre-producció descrita a la secció 9.2.2.4, usant l’abast de l’Edifici B com a objectiu de simulació: 24 switches, 8 Cisco, 8 Arista, 8 HPE.

Pas 1: Exportar la topologia de la Font de Veritat

El SoT conté l’inventari de switches de l’Edifici B amb les versions del SO previstes:

• 8 Cisco Catalyst 9300: IOS-XE 17.9.4
• 8 Arista 7050: EOS 4.31.2F
• 8 HPE Aruba 6300: AOS-CX 10.12.1006 (línia de firmware més antiga, pre-10.13)

L’exportació del SoT produeix una definició de topologia netlab: tipus de nodes, etiquetes d’imatge específiques del proveïdor associades a les versions del SO previstes i l’estat de VLAN amb el qual hauria de començar la simulació (VLANs existents 100, 150 i 200 ja configurades a tots els switches, coincidint amb l’estat de producció).

Pas 2: Instanciar l’entorn de simulació

netlab renderitza l’exportació del SoT en un fitxer de topologia de containerlab. containerlab s’executa en un amfitrió de simulació Linux compartit a l’entorn CI de l’equip (un servidor bare-metal amb 64 GB de RAM, suficient per a 24 contenidors cEOS/vrnetlab lleugers simultàniament). Els nodes HPE usen una imatge AOS-CX embolcallada per vrnetlab fixada a 10.12.1006, coincidint amb la versió del SO prevista del SoT. containerlab inicia la topologia. Els 24 nodes estan actius i responen a NETCONF i gRPC Network Management Interface (gNMI) en noranta segons.

Pas 3: Executar el flux de treball de VLAN del Capítol 7 contra l’objectiu de simulació

L’Orquestrador activa el flux de treball amb l’inventari de simulació com a abast objectiu en lloc de l’inventari de producció. Els primers quatre passos del flux de treball es completen sense problemes. El cinquè pas del flux de treball, fan-out d’execució entre tots els 24 switches simulats via l’Executor, retorna fallades.

Resultats: 8 nodes Cisco passen. 8 nodes Arista passen. 8 nodes HPE fallen.

Error dels nodes HPE: vlan-exists. La comprovació d’idempotència a l’adaptador HPE gestionava duplicate-vlan com a no-operació però no tenia cap gestor per a vlan-exists. L’Executor va retornar fallada, activant la compensació Saga: VLAN 210 eliminada de tots els nodes que l’havien rebuda.

No s’ha produït cap canvi en producció. El cost de la fallada és el temps d’arrencada del contenidor i trenta minuts d’investigació.

Pas 4: Diagnòstic i correcció

L’equip comprova les notes de llançament d’AOS-CX 10.12. L’error vlan-exists es va introduir al 10.11.1, substituint duplicate-vlan per a la detecció de VLANs duplicades. El llançament 10.13 va revertir a duplicate-vlan per a la consistència amb la resta de la línia de productes Aruba.

Correcció: afegir vlan-exists a la llista de codis d’error d’idempotència a l’adaptador HPE. El SoT s’actualitza amb una nota sobre el límit de la versió del SO (del 10.11 al 10.12.x retorna vlan-exists; el 10.13+ retorna duplicate-vlan).

Abans de tornar a executar, l’equip codifica l’estat post-canvi esperat com una prova pyATS o Robot Framework: després de completar-se el flux de treball, afirmar que la VLAN 210 existeix en tots els 24 nodes de simulació i que la compensació Saga no s’ha activat.

Pas 5: Tornar a executar en simulació

L’adaptador corregit s’executa contra la mateixa topologia de containerlab. Els 24 nodes passen. La Saga es completa sense compensació. El SoT mostra la VLAN 210 present a tots els nodes de l’Edifici B.

Pas 6: Desplegament en producció

L’Orquestrador activa el mateix flux de treball contra tot l’abast de producció: 800 switches, edificis A a F. Cada pas s’executa a través del mateix patró Saga validat en simulació. Zero fallades als nodes HPE. El tiquet de ServiceNow de l’equip d’aplicacions es tanca automàticament quan l’Orquestrador es completa. La capa d’Observabilitat valida la presència de la VLAN 210 a totes les interfícies dins de la finestra de temps esperada.

El que demostra

L’entorn de simulació no és un pas de verificació que es pot saltar quan l’equip se sent confiat. És la porta pre-producció al patró Saga. Una topologia de simulació que reflecteix la topologia de producció i les versions del SO és l’entorn de proves mínim viable per a un equip que desplega automatització a escala de campus. La inversió és la configuració de containerlab, les imatges fixades per versió del SO i un mecanisme d’exportació del SoT. La recompensa és la capacitat de capturar errors específics del dispositiu abans que es converteixin en incidents.

9.4. Resum#

El Capítol 9 tanca la Part 2 abordant el bloc al qual la plataforma d’automatització sempre apuntava: la pròpia xarxa.

Tres idees ancoren el capítol.

La xarxa no és uniforme. Qualsevol plataforma d’automatització a gran escala interactua simultàniament amb switching de campus, fabric de centre de dades, VPCs cloud, overlays de Kubernetes, controladors d’overlay i equips llegats. Cadascun exposa una interfície diferent, opera sota semàntiques de consistència diferents i té una maduresa d’automatització diferent. La plataforma absorbeix aquesta heterogeneïtat a través de la jerarquia de selecció d’interfície (gRPC Network Management Interface (gNMI) per a la telemetria, NETCONF per a la configuració, Command Line Interface (CLI) com a últim recurs), el seguiment de la versió del SO a la Font de Veritat i els adaptadors específics del proveïdor a l’Executor.

Els entorns de simulació són la porta pre-producció. L’emulació basada en contenidors proporciona entorns realistes, ràpids i integrats amb CI/CD on la lògica d’automatització es prova contra topologia i versions del SO que reflecteixen la producció. Les fallades en simulació són barates. Les fallades en producció són cares. La fidelitat de l’entorn de simulació a l’estat de producció és el que fa que la porta sigui significativa.

Les estratègies d’abstracció estenen la vida útil de la plataforma. El patró adaptador gestiona l’entorn físic multiproveïdor actual. OpenConfig i la traducció YANG avancen cap a models neutrals al proveïdor que redueixen el manteniment de l’adaptador a llarg termini. SONiC elimina completament el treball de l’adaptador per a les plataformes que el suporten. Cap d’aquestes estratègies proporciona una resposta perfecta; cadascuna implica compromisos entre la uniformitat i l’accés a les funcions. L’elecció correcta depèn del catàleg de dispositius de l’equip, la capacitat operativa i quant del seu treball d’automatització cau dins de la cobertura de funcions estàndard.

Amb el Capítol 9, la Part 2 és completa. Sis capítols han cobert tots els set blocs constructius del marc NAF: Font de Veritat, Collector i Observabilitat (junts al Capítol 6), Execució, Orquestració, Presentació i La Xarxa. No són eines independents. El SoT alimenta l’Executor amb la intenció que necessita i el Collector amb l’estat esperat per validar. L’Orquestrador els seqüencia tots dos, gestiona les fallades i presenta el progrés a la capa de Presentació. La Xarxa se situa per sota de tots ells: la restricció que ha conformat el disseny de cada altre bloc, i el lloc on l’automatització finalment produeix un resultat o falla.

La Part 3 passa de construir els blocs a operar la plataforma a escala: enginyeria per a la fiabilitat, disseny per a la seguretat i el compliment, i tractar la plataforma d’automatització com un producte amb el seu propi cicle de vida i requisits operatius.

Referències i Lectura Addicional#

• Network Programmability and Automation, Matt Oswalt, Christian Adell, Scott Lowe, Jason Edelman (O’Reilly, 2a ed. 2023). La guia pràctica més exhaustiva sobre les eines d’automatització de xarxes, cobrint NETCONF, gNMI, models YANG i marcs d’automatització en profunditat.
• Network Programmability with YANG, Benoit Claise, Loe Clarke, Jan Lindblad (Pearson, 2019). La referència definitiva sobre el modelatge de dades YANG: com s’estructuren els models IETF i OpenConfig, com llegir i escriure mòduls YANG, i com NETCONF i RESTCONF els usen.
• Cisco pyATS: Network Test and Automation Solution, John Capobianco, Dan Wade (Cisco Press). Una guia exhaustiva sobre pyATS i Genie per a l’automatització de proves de xarxa: scripts de proves, analitzadors, validació d’estat estructurada i integració de pipelines CI/CD.
• Infrastructure as Code, Kief Morris (O’Reilly, 2a ed. 2021). No específic de xarxa, però fonamental per entendre com els principis darrere de la infraestructura repetible, provable i versionada s’apliquen directament al disseny de la plataforma d’automatització de xarxes.

💬 Found something to improve? Send feedback for this chapter