Quando si parla di ridondanza di rete, molte infrastrutture vengono ancora progettate con un equivoco di fondo: si pensa che basti duplicare uno switch, aggiungere un secondo link o installare un firewall in coppia per poter parlare di alta disponibilità. In realtà la continuità operativa di una rete non dipende dalla semplice presenza di componenti duplicati, ma dal modo in cui questi componenti sono collegati, coordinati, documentati e testati. Una rete può avere apparati costosi e perfino ridondati sulla carta, ma restare fragile dal punto di vista operativo se la topologia contiene colli di bottiglia logici, single point of failure non dichiarati o meccanismi di failover non coerenti con i servizi realmente trasportati.
In un edificio direzionale o in un campus la questione è ancora più rilevante. La rete non sostiene soltanto utenti office, ma anche Wi-Fi, telefonia IP, videosorveglianza, controllo accessi, building systems, applicazioni centrali, storage, servizi di collaborazione e spesso collegamenti tra sedi o tra building. Ogni interruzione impatta funzioni diverse con priorità diverse. Per questo la ridondanza non può essere trattata come una funzione accessoria da aggiungere alla fine del progetto. Deve essere una scelta architetturale inserita fin dall’inizio nella struttura della rete.
Ridondanza non significa assenza di guasti
Un’infrastruttura ridondata non elimina i guasti. Li rende gestibili. Questo è il primo punto da fissare. L’obiettivo corretto non è costruire una rete “che non si ferma mai”, formula poco seria e quasi sempre usata male. L’obiettivo è ridurre la probabilità che un singolo evento interrompa un servizio critico, limitare l’impatto di un fault quando si verifica, rendere prevedibile il comportamento della rete durante il failover e accorciare il tempo necessario al ripristino pieno.
Per ottenere questo risultato occorre ragionare per livelli. C’è la ridondanza fisica dei collegamenti, la ridondanza degli apparati, la ridondanza del gateway, la ridondanza dei percorsi Layer 2 e Layer 3, la ridondanza delle alimentazioni, la ridondanza dei servizi centrali e la ridondanza della documentazione operativa, che è meno citata ma altrettanto importante. Se manca chiarezza su quale livello si sta proteggendo, la parola “ridondanza” diventa solo una formula commerciale.
Il primo rischio: il single point of failure nascosto
In quasi tutte le reti con problemi di disponibilità esiste almeno un punto debole non esplicitato. Può essere uno switch di distribuzione unico da cui passa tutto il traffico di piano, un uplink non ridondato tra armadio e core, un solo gateway di uscita per VLAN critiche, una singola dorsale ottica verso un building secondario, un firewall collocato correttamente ma alimentato da una sola linea, oppure una coppia di apparati formalmente presente ma configurata in modo non simmetrico.
Il problema non è solo tecnico. È progettuale. Una ridondanza efficace comincia dalla capacità di dichiarare quali componenti, percorsi o funzioni sono davvero singoli punti di guasto e quali invece hanno una via alternativa realmente percorribile. Se questa analisi non viene fatta, la rete può sembrare robusta finché tutto funziona, ma diventa imprevedibile proprio nel momento in cui dovrebbe proteggere il servizio.
LACP: più capacità, più resilienza, ma entro un perimetro preciso
Uno dei meccanismi più usati è il link aggregation. Lo standard IEEE 802.1AX definisce la possibilità di utilizzare più link punto-punto come se fossero un unico collegamento logico, con finalità di load sharing e resilienza tra nodi di rete.
Questo è il primo punto da capire bene: LACP non è solo un modo per “sommare banda”. È anche un meccanismo utile per contenere l’impatto del guasto di un singolo link all’interno di un bundle. Se un collegamento fisico cade, il port-channel continua a trasportare traffico sugli altri membri attivi, a condizione che il bundle sia stato progettato correttamente e che la capacità residua sia compatibile con il carico reale.
Ma qui bisogna essere rigorosi. LACP protegge dal guasto di un membro del bundle; non protegge automaticamente dal guasto dell’intero apparato a cui il bundle è attestato. Se tutti i link aggregati terminano sullo stesso switch e quello switch si ferma, il bundle non salva nulla. È una distinzione fondamentale, spesso ignorata. Per ottenere vera resilienza di apparato bisogna combinare il link aggregation con architetture capaci di distribuire i collegamenti su nodi diversi, per esempio con soluzioni di Multi-Chassis Link Aggregation. Arista, per esempio, descrive l’MLAG come un meccanismo che consente di aggregare logicamente porte distribuite su due switch distinti, evitando di sprecare banda con porte bloccate in spanning tree e offrendo un comportamento più resiliente a Layer 2.
Da un punto di vista progettuale, la lezione è chiara: il bundle è utile quando si conosce bene il livello di protezione che offre. È ottimo per aumentare capacità e tolleranza al fault di singolo link. Diventa architettura di alta disponibilità solo quando è inserito in una topologia coerente, con apparati, percorsi e policy di failover pensati per lavorare insieme.
STP, RSTP e il controllo dei loop
Ogni volta che si costruiscono percorsi Layer 2 ridondati compare un rischio inevitabile: il loop. Per questo il ruolo dello spanning tree resta centrale in molte architetture Ethernet, soprattutto negli strati di accesso e distribuzione in cui esistono più collegamenti ridondanti.
La versione storica 802.1D è nata in un’epoca in cui tempi di riconvergenza dell’ordine di decine di secondi o di circa un minuto erano considerati accettabili. L’evoluzione 802.1w, cioè RSTP, ha introdotto meccanismi di convergenza più rapidi e una transizione più veloce verso lo stato forwarding, mantenendo la compatibilità con il modello spanning tree classico. Cisco descrive chiaramente questo salto: RSTP offre prestazioni migliori rispetto al vecchio STP e incorpora una logica di convergenza più rapida, con uso più attivo delle BPDUs e gestione migliorata di port roles e transizioni.
In termini pratici, questo significa che la ridondanza Layer 2 non può essere pensata come una semplice moltiplicazione dei link. Deve sempre essere accompagnata da una logica di controllo dei percorsi. STP, RSTP o MSTP non servono a “rallentare” la rete: servono a impedire che la ridondanza degeneri in instabilità.
Anche qui, però, esiste un punto critico. Affidare tutta la disponibilità di una rete a un design Layer 2 esteso, con percorsi ridondanti e spanning tree distribuito su ampi domini, spesso non è la scelta più matura. In molte architetture moderne conviene contenere il Layer 2, spingere il controllo verso Layer 3 dove possibile e usare lo spanning tree in modo disciplinato, non come rimedio universale. La rete diventa più leggibile, il troubleshooting migliora e la convergenza tende a essere più prevedibile.
Gateway redundancy: il default gateway non può essere un punto singolo
In una rete segmentata, ogni VLAN o subnet deve avere un gateway. Se il gateway è unico, il suo guasto interrompe l’uscita dal dominio, anche quando gli switch, i link e le dorsali restano perfettamente attivi. Qui entra in gioco la gateway redundancy.
VRRP è stato progettato proprio per eliminare il single point of failure tipico dell’ambiente static default-routed. L’RFC 5798 definisce un meccanismo elettivo che assegna dinamicamente la responsabilità di un virtual router a uno dei router partecipanti sulla LAN, così che uno gestisca l’indirizzo virtuale attivo e gli altri restino pronti al subentro.
La funzione è chiara: il client continua a usare un gateway virtuale stabile, mentre dietro quel riferimento la responsabilità può passare da un apparato all’altro. Sul piano operativo, questo riduce l’impatto del fault di un singolo nodo gateway. Ma, anche in questo caso, la sola presenza di VRRP non basta. Conta dove si trovano gli apparati, come sono collegati a valle e a monte, come si comportano le VLAN in caso di fault, se i percorsi verso il core o verso il firewall restano disponibili e se la capacità residua del nodo superstite è adeguata al traffico reale.
La gateway redundancy, quindi, non è una funzione da configurare e dimenticare. È una parte della continuità di servizio e va verificata in relazione ai flussi concreti della rete.
Ridondanza di collegamento, di apparato e di percorso: tre piani diversi
Molti problemi nascono perché questi tre piani vengono confusi.
La ridondanza di collegamento protegge il singolo link. È il caso tipico del doppio uplink o del bundle LACP. Serve a evitare che il guasto di una sola tratta interrompa il servizio.
La ridondanza di apparato protegge il nodo. Qui servono due switch, due router, due firewall o due gateway con logiche di cooperazione e subentro. Se c’è un solo apparato al centro, la rete resta vulnerabile anche con più cavi.
La ridondanza di percorso protegge il cammino complessivo del traffico. È il livello più maturo. Non basta che esistano due link o due apparati: occorre che il traffico possa davvero transitare attraverso un percorso alternativo indipendente, con policy, routing e capacità compatibili con il servizio richiesto.
Quando questi tre piani sono allineati, la rete acquista robustezza reale. Quando uno dei tre manca, la ridondanza esiste solo parzialmente.
Edifici e campus: la disponibilità cambia scala
In un edificio singolo si può spesso costruire una buona disponibilità con access switch doppiamente collegati, distribuzione ridondata, gateway ridondati, uplink bundle e un core ben documentato. In un campus il problema cambia scala. Entrano in gioco interconnessioni tra building, armadi distanti, percorsi fisici separati, eventuali tratte ottiche ridondate, distribuzioni locali e centrali, servizi condivisi tra strutture diverse e fault domain che devono essere progettati in modo esplicito.
Qui il punto critico è evitare sia la semplificazione eccessiva sia la complessità gratuita. Una rete campus con troppi elementi Layer 2 estesi, troppe dipendenze trasversali e poca disciplina documentale rischia di diventare difficile da governare proprio quando si verifica un fault. Una rete campus ben progettata, invece, distingue chiaramente i domini locali, organizza i percorsi di riserva, decide dove deve convergere il traffico e definisce in anticipo cosa succede quando cade un link, un nodo o un’intera tratta tra building.
La continuità reale dipende anche da energia, ottiche e cablaggio
Qui spesso si commette un altro errore: si parla di alta disponibilità di rete come se riguardasse solo protocolli e apparati attivi. Non è così. Una buona parte della resilienza dipende dall’infrastruttura fisica che sostiene la rete.
Due switch ridondati ma alimentati dalla stessa linea elettrica, due percorsi ottici che passano nella stessa canalizzazione, due firewall attestati allo stesso armadio senza separazione reale dei percorsi, un access switch con doppio uplink ma una sola dorsale di building: tutti questi casi mostrano una disponibilità solo apparente.
La ridondanza vera coinvolge alimentazioni, UPS, percorsi cavi, distribuzione delle tratte ottiche, cabinet tecnici, ventilazione e documentazione delle connessioni. È qui che la rete smette di essere solo networking e torna a essere infrastruttura. Ecco perché, nei progetti seri, architettura di rete e cablaggio strutturato vanno sempre ragionati insieme.
Gli errori che compromettono la disponibilità
Ci sono alcuni errori ricorrenti che degradano la ridondanza più di quanto si creda.
Il primo è la ridondanza simmetrica solo in apparenza: due apparati, ma uno solo davvero instradante o con policy aggiornate.
Il secondo è l’assenza di test. Molte reti dichiarano il failover ma non lo provano mai in condizioni realistiche.
Il terzo è il sovradimensionamento teorico senza verifica del carico in fault mode: quando un nodo cade, la capacità residua deve essere sufficiente.
Il quarto è l’eccesso di Layer 2 esteso dove sarebbe più corretto usare un disegno Layer 3 più leggibile.
Il quinto è la documentazione incompleta. Durante un fault, sapere in pochi minuti quali uplink, bundle, gateway e policy sono davvero coinvolti fa la differenza tra un disservizio contenuto e un fermo lungo.
Testare la ridondanza è parte del progetto
Una rete non è davvero ad alta disponibilità finché non è stata provata in scenari di guasto credibili. Serve verificare la perdita di un link membro in un bundle, il fault di un uplink completo, il guasto di uno switch di distribuzione, il cambio di master del gateway virtuale, il comportamento di STP o RSTP in topologie ridondate, la tenuta dei servizi voice e video durante la riconvergenza e la leggibilità degli allarmi a sistema.
Questo passaggio è essenziale perché molte architetture funzionano bene in stato nominale e male proprio nella condizione che dovrebbero proteggere. Il test rivela incoerenze di configurazione, dipendenze nascoste e limiti di capacità che sulla carta restano invisibili.
Conclusione
La ridondanza di rete non è una somma di tecnologie, ma una disciplina di progetto. LACP, STP, gateway redundancy e soluzioni di dual-homing o multi-chassis hanno tutti un ruolo importante, ma solo se inseriti in un disegno coerente. LACP protegge il link e può aumentare la capacità; STP e le sue evoluzioni impediscono che la ridondanza Layer 2 degeneri in loop; i meccanismi di gateway redundancy evitano che il default gateway diventi un punto singolo di guasto; la vera alta disponibilità nasce però solo quando apparati, percorsi, energia, policy e test si tengono insieme.
In edifici e campus la continuità operativa non dipende dal numero di componenti installati, ma dalla qualità delle relazioni tra quei componenti. È questo che distingue una rete semplicemente ridondata da una rete progettata per restare utile, leggibile e stabile anche quando qualcosa si rompe.
Riferimenti tecnici usati per la stesura: IEEE 802.1AX per il Link Aggregation, documentazione Cisco su RSTP/802.1w e convergenza spanning tree, RFC 5798 per VRRP, documentazione Arista su MLAG come aggregazione logica distribuita su due chassis.
