Aggiornamento firmware degli switch senza interruzione di servizio: strategia di rollout, verifiche e piano di rollback

Un aggiornamento del firmware dello switch senza downtime sembra una promessa che nella pratica spesso fallisce sui dettagli: un singolo uplink senza LACP, un percorso STP impostato in modo errato, uno stack con modelli misti o un’immagine che avvia ma attiva nuovi default. Allo stesso tempo gli aggiornamenti firmware non sono un „nice to have“. Chiudono falle di sicurezza, risolvono memory leak, migliorano l’interoperabilità (ad es. con LACP, BGP/EVPN o PoE) e stabilizzano il funzionamento.

Questo contributo mostra come pianificare e distribuire gli aggiornamenti del firmware in modo che utenti e sistemi idealmente non se ne accorgano. Il focus non sono i comandi specifici del produttore, ma la logica operativa: quale ridondanza è effettivamente necessaria, quali verifiche sono imprescindibili in anticipo, come si struttura un rollout graduale su Access/Distribution/Core e come deve essere un piano di rollback solido – inclusi i tipici ostacoli e i punti di monitoraggio.

Perché «senza downtime» sugli switch a volte è corretto – e a volte no

«Senza downtime» significa nelle reti di solito: nessuna interruzione percepibile per i servizi connessi. Tecnicamente possono comunque verificarsi eventi brevi: singole perdite di pacchetti, una riconvergenza di routing, un STP-Topology-Change o un link-flap. Se questo venga considerato downtime dipende dalle vostre applicazioni (VoIP, OT, Storage, VDI), dai timeout e dalla vostra ridondanza.

Importante: un aggiornamento del firmware non è automaticamente „hitless“. I produttori offrono meccanismi come ISSU (In-Service Software Upgrade, aggiornamento in servizio), „non-disruptive upgrade“, „rolling upgrade“ negli stack o percorsi di upgrade per MLAG/vPC. Queste procedure funzionano solo se sono soddisfatte determinate condizioni: revisioni hardware compatibili, combinazioni di feature-set supportate, immagini identiche, versioni compatibili del bootloader, un design corretto della Dual-Control-Plane o partner LACP stabili.

Prerequisiti di base per un aggiornamento del firmware dello switch senza downtime

Se potete davvero aggiornare senza interruzioni percepibili si valuta in fase preliminare. Verificate questi punti prima ancora di scaricare un’immagine:

1) La ridondanza non è un’etichetta, ma una prova

„Dual-homed“ è affidabile solo se ogni connessione critica è ridondata – e lo è fino al livello successivo (Distribution/Core) e oltre fino ai gateway di routing. Pattern tipici:

• LACP (Link Aggregation Control Protocol): aggrega più link fisici in un unico port-channel logico. Se un link viene a mancare, il channel rimane operativo. Prerequisiti: hashing corretto, MTU identica, stesse impostazioni VLAN e STP su tutte le porte membri.
• MLAG/vPC: due switch appaiono verso il downstream come un unico partner LACP logico. Vantaggio: ridondanza senza STP-blocking sugli uplink di accesso. Rischio: il design del peer-link/keepalive e la protezione contro lo split-brain devono essere implementati correttamente.

Se un Access-Switch ha un solo uplink o un server utilizza una sola NIC senza bonding/teaming, lì non è raggiungibile il risultato „senza downtime“. Allora l’obiettivo diventa piuttosto: minimizzare i tempi di inattività e controllarli.

2) Control Plane vs. Data Plane verstehen

Per gli operatori la separazione è decisiva: la Data Plane inoltra i pacchetti (ASICs/forwarding), la Control Plane calcola tabelle e vicinanze (STP, OSPF/BGP, ARP/ND). Un hitless upgrade cerca di mantenere il forwarding il più a lungo possibile stabile, mentre la Control Plane si riavvia o viene trasferita a un secondo supervisor/route-engine. Ciò può fallire se si usano feature non supportate durante ISSU (ad es. alcuni moduli di telemetria, PBR, profili QoS speciali, MACsec, combinazioni VXLAN/EVPN a seconda del release).

3) Management-Zugang und Out-of-Band müssen stehen

Senza OOB-Management (Out-of-Band, rete di management separata) un rollout è rischioso: se la rete in-band vacilla brevemente, perdete l’accesso proprio quando vi serve. Minimo necessario: AAA coerente (RADIUS/TACACS), account di fallback locali, console server raggiungibili o processo di Remote-Hands.

4) Konfigurations- und Zustandsdaten sichern

Un firmware upgrade non modifica solo il software, ma talvolta anche: bootloader, valori di default, feature-flag, formati di database per configurazione o store di certificati/chiavi. Salvate quindi:

• configurazione attiva (running) e di avvio (startup)
• set di immagini correnti (incl. immagine secondaria/di backup, se presente)
• inventario: modello, numero di serie, revisione hardware, stato PSU/ventole
• stati operativi critici: STP-Root, stato MLAG/vPC, adiacenze di routing, stato dei Port-Channel

Rollout-Strategie: So planen Sie den Upgrade-Pfad über Access, Distribution und Core

La migliore strategia di upgrade si orienta sui domini di guasto e sulle dipendenze. Un principio semplice e nella pratica robusto: prima i margini, poi il centro – ma con attenzione.

Phase 0: Readiness-Check und Change-Plan

Redigete un piano di change che non si limiti a „eseguire l’upgrade“, ma contenga criteri misurabili: Go/No-Go, soglie di monitoring, trigger di rollback, canale di comunicazione e calendario. Se operate in ottica ITIL: il Backout-Plan è obbligatorio, ma deve essere tecnicamente eseguibile (vedi oltre).

Phase 1: Lab/Canary – eine repräsentative Teilmenge

Iniziate con un Canary: uno switch o una coppia (MLAG/vPC) in un segmento rappresentativo (stesse funzionalità, VLAN simili, stessi Optics/Transceiver) – ma operativamente tollerabile. L’obiettivo non è solo che «si avvii», ma: funzioni in modo stabile sotto il vostro carico e il vostro monitoraggio.

Fase 2: Aggiornamento rolling dell’Access Layer

Gli switch di accesso sono spesso numerosi, ma singolarmente meno critici. Se gli endpoint sono dual-homed (ad es. server con LACP verso due switch di accesso o verso una coppia MLAG), potete aggiornare i dispositivi di accesso uno dopo l’altro. Se gli endpoint sono single-homed, definite esplicitamente che brevi interruzioni sono possibili – e pianificatele in una finestra di manutenzione.

Fase 3: Distribution/Leaf – a coppie e con verifiche dello stato

Nella Distribution (o livello Leaf nel design Spine-Leaf) i meccanismi MLAG/vPC/EVPN sono più frequenti. Qui l’upgrade „senza downtime“ diventa realistico se procedete a coppie: prima lo switch A, verificate la stabilità, poi lo switch B. È fondamentale che i Peer-Links und Keepalives rimangano stabili durante l’operazione.

Fase 4: Core/Spine – solo con convergenza di routing garantita

Nel Core o nel layer Spine l’impatto è maggiore. Anche se i percorsi dati sono ridondanti, un riavvio del control plane può rinegoziare BGP/OSPF. Pianificate qui con consapevolezza: evitate modifiche alle route-policy, non toccate i timer ‚on the fly‘, e verificate in anticipo se le vostre applicazioni tollerano brevi eventi di routing. Per le reti di storage (iSCSI/NFS) la regola è: pianificare in modo particolarmente conservativo, poiché brevi perdite di pacchetti possono già compromettere le sessioni.

Trappole tipiche che fanno fallire il ‚hitless‘ nella pratica

Molte interruzioni durante il rollout del firmware non sono bug misteriosi, ma schemi ricorrenti:

• Ridondanza asimmetrica: esistono due uplink, ma solo uno trasporta VLAN o la MTU è diversa. In caso di failover si verifica blackholing.
• Sorprese STP: Spanning Tree (evitare loop a Layer 2) reagisce agli eventi di link. Un upgrade può innescare topology-change che portano a blocking temporaneo – particolarmente se il root è posizionato in modo errato o se le impostazioni PortFast/Edge sono incoerenti.
• MLAG/vPC-Split-Brain: il peer-keepalive viaggia sulla stessa rete del peer-link o è troppo fragile. Se viene a mancare, possono verificarsi situazioni dual-active.
• Stack con generazioni miste: l’aggiornamento rolling è limitato o non possibile. Un membro si riavvia e trascina con sé lo stato dello stack.
• Compatibilità Transceiver/Optics: dopo l’upgrade le Optics di terze parti possono essere sottoposte a controlli più stringenti o l’interpretazione di DOM/EEPROM può cambiare. Risultato: i link restano down.
• Dipendenze Bootloader/ROMMON: la nuova immagine richiede un aggiornamento del bootloader. Se saltato, lo switch potrebbe non avviarsi dopo il reboot.
• Feature-Flags e default: le funzionalità di sicurezza (ad es. default crittografici SSH più restrittivi, versioni TLS, obblighi SNMPv3) possono cambiare. Gli strumenti di gestione perdono l’accesso.

Verifiche preliminari: checklist per inventario, compatibilità e rischio

Le seguenti verifiche sono formulate in modo da poter essere integrate nel vostro runbook. I comandi dei vendor variano, la logica rimane la stessa.

Inventario e dipendenze (obbligatorio)

• Versione firmware corrente e versione target pianificata; verificare se è necessario un passaggio intermedio (percorso di upgrade).
• Revisioni hardware, membri dello stack, moduli Supervisor/RE, stato PSU/ventole.
• Feature utilizzate: MLAG/vPC, VXLAN/EVPN, MACsec, PBR, NetFlow/sFlow, telemetria, DHCP Snooping, Dynamic ARP Inspection, 802.1X.
• Gestione: AAA, policy SSH, SNMP (v2c/v3), Syslog, NTP, certificati.
• Sistemi dipendenti: NAC, monitoring, backup configurazione, IPAM/DCIM, tooling di automazione.

Validazione della ridondanza (evidenza anziché assunzione)

Testate il failover prima dell’upgrade. Il test deve essere realistico: non limitarsi a „staccare il link“, ma verificare anche se il traffico viene effettivamente reindirizzato. Passaggi sensati:

1. Rilevare baseline (latenza, perdita di pacchetti, contatori errori delle interfacce, CPU/memoria degli switch).
2. Disattivare brevemente l’uplink A, osservare: le sessioni restano stabili, STP/routing converge, aumenta la perdita di pacchetti?
3. Riattivare l’uplink A, stessa osservazione.
4. Lo stesso per l’uplink B.

Se il failover non funziona correttamente già in normale esercizio, un upgrade del firmware non risolverà il problema — lo renderà solo visibile.

Prontezza di monitoring e logging

Per un upgrade senza downtime servono „occhi e orecchie“: SNMP/streaming-telemetria, Syslog, eventualmente tracking degli errori delle interfacce. Prestare attenzione ai contatori che risultano sensibili durante gli upgrade: CRC/Alignment Errors, Input Drops, STP TCNs (Topology Change Notifications), LACP-Flaps, BGP Neighbor Down/Up.

Implementazione in esercizio: piano a fasi comprensivo di pre- e post-check

Di seguito un piano a fasi indipendente dal vendor. Usatelo come modello per il vostro runbook; integrate i comandi CLI specifici della vostra piattaforma.

Fase 1: Pre-Check immediatamente prima del change

• Change-freeze per le modifiche parallele (firewall, routing, VLAN, storage), per separare gli effetti.
• Backup della configurazione (automatizzato + verificato manualmente che sia leggibile).
• Testare l’accesso di management: OOB raggiungibile, login OK, privileged mode OK.
• Check di integrità: nessun link in flapping, nessun tasso di errori elevato, nessun neighbor di routing instabile.

Fase 2: Gestione delle immagini e integrità

Non caricate le immagini da „qualsiasi fonte“ sullo switch. Utilizzate una fonte controllata (repo interno, download firmati dal vendor) e verificate l’integrità (hash) e lo spazio su disco. Esempio di verifica hash su un host di amministrazione:

# Beispiel: SHA256-Hash einer Firmware-Datei prüfen
sha256sum switch-firmware.bin
# Erwarteten Hash aus Herstellerquelle/Release-Notes gegenprüfen

Perché è importante: immagini danneggiate causano boot-loop o strani errori a runtime che si manifestano solo dopo il reboot. La verifica dell’hash è una protezione semplice e economica.

Passo 3: Rolling Upgrade per coppie (MLAG/vPC) – Principio

Con una coppia di switch il principio è sempre simile, a prescindere dalla denominazione: si mantiene un nodo in servizio mentre l’altro esegue l’upgrade e riavvia. Determinanti sono tre verifiche:

• Peer-Link/Interconnect stabile: il nodo rimanente deve mantenere correttamente lo stato della coppia.
• Downstream-LACP stabile: server/Access devono continuare a portare avanti i loro bundle.
• Gateway/Anycast stabile: se utilizzate gateway Anycast, il failover deve avvenire in modo pulito.

Praticamente significa: eseguire l’upgrade del nodo A, attendere che sia completamente rientrato nel cluster, che lo stato sia sincronizzato, quindi procedere con il nodo B.

Passo 4: Upgrade negli Stack – Particolarità

Nel stacking i membri spesso condividono una control plane. Alcune piattaforme consentono upgrade «hitless/rolling», altre riavviano l’intero stack come unità. Verificate quindi in anticipo:

• Il modello/versione dello stack supporta un aggiornamento hitless/rolling?
• La topologia dello stack è ridondata (ring invece che line), in modo che il riavvio di un membro non spezzi lo stack?
• Qual è il ruolo del master (Active) e come avviene uno switchover?

Se il rolling non è supportato, l’«assenza di downtime» è ottenibile solo se i dispositivi terminali sono collegati in modo ridondante al di fuori dello stack (es. dual-homing verso due stack separati) — altrimenti si verifica un’interruzione percepibile.

Passo 5: Controlli post-operazione – non solo «il ping funziona»

Molti team chiudono una change dopo un login riuscito. Per la stabilità serve di più:

• Port-Channel/LACP: tutti i member su, nessun «suspended», nessun ribilanciamento anomalo.
• STP: root-bridge come previsto, nessun topology-change inatteso, nessuna porta in stato errato.
• Routing (se Layer-3): vicini up, rotte complete, ECMP attivo, nessun flap.
• Errori di interfaccia: CRC/Input Errors/Drops non in aumento.
• Management: SNMP/Telemetry consegna, Syslog arriva, NTP sincronizzato, AAA OK.

Solo quando questi punti risultano stabili si procede con lo switch successivo.

Piano di rollback: cosa funziona realmente in caso di emergenza

Un rollback non è un «reinstalliamo la vecchia immagine», ma una procedura meccanica che funzioni anche sotto stress. Pianificate il rollback in modo che sia eseguibile entro la finestra di interruzione massima tollerata (RTO nel gergo operativo: Recovery Time Objective).

Definire i trigger di rollback (prima!)

Senza trigger chiari i team discutono troppo a lungo. Trigger tipici che giustificano un rollback immediato:

• Core/Distribution: instabilità di routing (neighbor-flap) che non si stabilizza entro pochi minuti
• MLAG/vPC: indicatori di dual-active/split-brain, Peer-Link instabile
• Massicci errori di interfaccia dopo l’upgrade (CRC/Drops in forte aumento)
• Perdita del management: nessun accesso via OOB e inband, solo remote hands
• Incompatibilità inaspettata: optics/PoE/802.1X che cadono su vasta scala

Meccaniche di rollback: immagine, configurazione, variabili di boot

In pratica esistono tre livelli di rollback:

1. Boot su Secondary/Backup-Image: molti switch possono mantenere una seconda immagine. È il metodo più rapido quando il nuovo image è fondamentalmente la causa del problema.
2. Downgrade-Install: reinstallazione della versione precedente. Attenzione: alcune piattaforme non consentono un downgrade diretto attraverso determinate release major.
3. Konfigurations-Rollback: se l’immagine è OK, ma i default delle feature o le modifiche al parser interpretano la configurazione diversamente, serve un backup di configurazione verificato e, se necessario, delle modifiche ad hoc.

Pianificate esplicitamente quale livello ripristinare per primo. E: mantenete la vecchia Firmware disponibile localmente (Repo + percorso di trasferimento raggiungibile), non solo “su Internet”.

Il test di rollback nel Canary è obbligatorio

L’errore di rollback più frequente: nessuno l’ha esercitato. Nella configurazione Canary dovreste quindi eseguire almeno una volta il «boot sulla immagine precedente» e il ripristino di un backup di configurazione. Obiettivo: sapere quanto tempo richiede e quali stati intermedi sono critici (ad es. sincronizzazione MLAG temporaneamente assente).

Risoluzione dei problemi durante e dopo l’aggiornamento: percorsi di diagnosi rapida

Se dopo l’aggiornamento qualcosa è “strano”, aiuta un percorso di diagnosi breve e standardizzato, invece di cliccare freneticamente in tutte le direzioni.

Sintomo: i dispositivi perdono brevemente la connessione

• Controllare: LACP/Port-Channel flapping? STP Topology Changes? eventi di link sugli uplink?
• Perché succede: un member-link si riavvia, LACP si rinegozia, STP ricalcola. Se Edge/PortFast è impostato in modo errato, ci vuole più tempo.
• Contromisura: impostare correttamente STP-Edge, parametri LACP coerenti, validare i percorsi ridondanti.

Sintomo: vicini (OSPF/BGP) vanno in flapping, anche se i link sono up

• Controllare: spike di CPU/memoria dopo il boot, timer/keepalive, MTU, ACL/CoPP (Control Plane Policing).
• Perché succede: il Control Plane impiega più tempo dopo l’aggiornamento; nuovi default per CoPP o per le routing policy entrano in vigore.
• Contromisura: attendere stabilità (tempo definito), quindi verificare i trigger di rollback; confrontare le policy.

Sintomo: singoli VLAN/servizi “scompaiono”

• Controllare: liste VLAN consentite sul trunk, VLAN nativa, database VLAN, signaling VTP/EVPN a seconda del design.
• Perché succede: modifiche al parser, nuovo comportamento di default per frame untagged, acquisizione errata di template.
• Contromisura: diff di configurazione rispetto al backup, riapplicazione mirata delle sezioni critiche.

Automazione e documentazione: meno errori di battitura, migliore tracciabilità

Anche se non adottate la piena automazione: un aggiornamento beneficia di procedure standardizzate. Due componenti pragmatici:

• Backup della configurazione e diff: effettuare backup automatizzati giornalieri e creare prima della modifica un “Golden Backup”. I diff aiutano a individuare effetti collaterali.
• Runbook come checklist: sequenza di passi con timestamp, responsabili, checkpoint, trigger di rollback. Sembra burocratico, ma riduce gli errori sotto stress.

Se già automatizzate le rollout di rete: integrate i Pre-/Post-Checks come task separati (ad es. stato delle interfacce, vicinanze, contatori di errori). Per molti team è sensato iniziare con approcci dichiarativi all’automazione. A tal proposito, una lettura approfondita della guida su Automazione di rete con Ansible per configurazione switch, backup e rollback può aiutare a rendere riproducibili gli upgrade-runbook.

Conclusione: gli aggiornamenti firmware senza downtime sono una questione di architettura e processo

Un aggiornamento firmware degli switch senza interruzioni di servizio riesce quando la ridondanza non è solo presente, ma funziona in modo dimostrabile, e quando i meccanismi di upgrade (ISSU, Rolling, MLAG/vPC) sono adeguati alla vostra topologia. Determinanti sono verifiche preliminari accurate, un rollout graduale (Canary → Access → Distribution → Core) e un piano di rollback che sia collaudato e dotato di trigger chiari. Così l’aggiornamento firmware si trasforma da evento a rischio a change di routine controllato – con servizi stabili e un funzionamento tracciabile.

Per questo tema sono inoltre rilevanti l’aggiornamento del firmware degli switch e l’upgrade dello stacking. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.