13 dic 2025·8 min
Spanning Tree di Radia Perlman: l'ossatura silenziosa di Ethernet
Conosci Radia Perlman e scopri come lo Spanning Tree Protocol previene i loop Ethernet, abilita la ridondanza e ha reso le reti grandi stabili e affidabili.
Conosci Radia Perlman e scopri come lo Spanning Tree Protocol previene i loop Ethernet, abilita la ridondanza e ha reso le reti grandi stabili e affidabili.
Ethernet è nato come un modo semplice per collegare computer nello stesso edificio. Quando si è diffuso in uffici, campus e data center, le aspettative sono cambiate: le reti locali non erano più solo “comode da avere”, sono diventate il condotto per email, condivisione file, stampanti, telefoni e infine interi flussi di lavoro aziendali. Quando quel condotto si rompeva, tutto a monte smetteva di funzionare.
I progettisti di rete hanno imparato anche una lezione importante sulla resilienza: se progetti una rete con un solo percorso tra i dispositivi, un singolo cavo o switch guasto può mettere fuori servizio un’intera area. La soluzione ovvia è la ridondanza—link e switch in più.
Al livello 2 di Ethernet, però, la ridondanza ha un effetto collaterale pericoloso: i loop.
Radia Perlman ha progettato lo Spanning Tree Protocol (STP), il meccanismo che permette alle reti Ethernet di avere ridondanza senza collassare a causa dei loop. Il suo contributo non è stato “tubi più grandi”—è stato un modo distribuito e pratico perché gli switch si coordinino, concordino una struttura di inoltro sicura e si adattino automaticamente quando la topologia cambia.
STP è il tipo di sistema che noti solo quando manca o è mal configurato. Quando funziona, nulla sembra speciale: il traffico scorre, i link restano attivi e la rete tollera i guasti. Blocca silenziosamente il numero minimo di percorsi necessario per evitare i loop, mantenendo comunque alternative pronte nel caso un percorso attivo si rompa.
Renderemo il problema tangibile mostrando cosa accade in un loop Ethernet e perché provoca tempeste e outage. Poi spiegheremo l’idea fondamentale dietro STP—come conserva la ridondanza eliminando i loop—e spiegheremo, in termini semplici, come gli switch decidono quali link inoltrare e quali mettere in riserva. Alla fine avrai un modello intuitivo per comprendere perché STP è diventato fondamentale nello switching di Layer 2 e perché il progetto di Perlman conta ancora, anche se Ethernet è cresciuto molto oltre le sue origini in ufficio.
Le prime reti Ethernet erano spesso piccole e lineari: una manciata di macchine su un segmento condiviso, o qualche switch (e “bridge”, il termine più vecchio) che collegava segmenti. Se un cavo veniva scollegato, si notava subito—ma il guasto era semplice da comprendere.
Man mano che le organizzazioni aggiungevano stanze, piani e edifici, la rete raramente cresceva come un progetto ordinato. Cresceva come un organismo vivente: un nuovo switch qui, un cavo “di emergenza” lì, una soluzione temporanea che diventava permanente.
Quando le reti si espandono così, si aggiungono link per motivi pratici:
Ogni modifica può sembrare innocua. Collettivamente, possono però creare percorsi multipli tra gli stessi switch.
La ridondanza è desiderabile perché migliora la disponibilità. Se un link fallisce, il traffico può prendere un altro percorso e gli utenti restano produttivi.
Ma al Layer 2 (switching), Ethernet non è progettata per “scegliere” automaticamente un percorso e ignorare gli altri. Gli switch inoltrano i frame basandosi sugli indirizzi appresi e, senza un piano di controllo, più percorsi possono formare un loop.
Questo è il nodo centrale: più cavi possono accidentalmente rompere la rete. Le stesse connessioni aggiunte per rendere le cose più sicure possono generare condizioni in cui il traffico circola all’infinito, sovraccaricando link e dispositivi. Spanning Tree è nato per mantenere i vantaggi della ridondanza prevenendo questi outage auto-inflitti.
Un loop di switching Ethernet accade quando esistono due o più percorsi Layer 2 attivi tra gli stessi switch—spesso perché qualcuno ha aggiunto un cavo di backup, ha collegato due uplink alla stessa rete o ha creato un anello senza un meccanismo di controllo. I frame non hanno un limite di hop a livello 2, perciò possono circolare indefinitamente.
Alcuni tipi di traffico devono essere floodati: broadcast (come le richieste ARP) e frame a destinazione sconosciuta (quando uno switch non sa ancora quale porta porta a un indirizzo MAC). In un loop, quel frame floodato viene copiato e inviato intorno all’anello, replicato ancora e ancora.
Un esempio semplice: un PC chiede “Chi ha 10.0.0.5?” via ARP (broadcast). Con un loop, ogni switch ripete il broadcast su più porte e le copie ripetute tornano indietro ad altri switch. Molto rapidamente, link e CPU degli switch si occupano soprattutto di gestire duplicati, lasciando poco spazio per il traffico reale.
Gli switch imparano dove sono i dispositivi osservando da quale porta arriva un MAC sorgente. In un loop, i frame dello stesso dispositivo possono arrivare su porte diverse a pochi millisecondi di distanza. Lo switch continua a “cambiare idea” su dove si trovi quel MAC, riscrivendo la tabella ripetutamente. Il risultato è traffico inoltrato sulla porta sbagliata, poi floodato, poi nuovamente mal appreso.
Questi effetti si combinano in sintomi noti: rallentamenti improvvisi in tutta la rete, disconnessioni intermittenti, telefoni che cadono, Wi‑Fi “che funziona ma è inutilizzabile” e talvolta un outage completo quando gli switch si saturano e smettono di rispondere. Un singolo cavo patch messo per errore può mettere fuori servizio molto più dei due dispositivi che collega.
Ethernet prende la sua resilienza dall’avere più di un percorso possibile tra gli switch. Se un cavo si taglia, il traffico può prendere un altro percorso. Il problema è che i percorsi extra possono creare accidentalmente un cerchio—e i frame Ethernet non hanno un campo “time to live” per fermarli.
Spanning Tree Protocol (STP) risolve questo con un accordo semplice: mantieni i link ridondanti fisicamente connessi, ma disabilita logicamente alcuni di essi così che la rete attiva formi un albero senza cicli.
Pensa a una città che costruisce strade extra così le ambulanze possano raggiungere ogni quartiere quando c’è una chiusura. Se la città aprisse tutte le strade senza regole, si potrebbero creare percorsi circolari confusi dove gli autisti girano senza sosta.
STP funge da controllo del traffico:
Una parte chiave del progetto di Radia Perlman è che non si basa su un controller che dice a ogni switch cosa fare. Ogni switch partecipa, scambiando piccoli messaggi e arrivando indipendentemente alla stessa conclusione su quali link devono inoltrare e quali stare in riserva.
Questo rende STP pratico nelle reti reali: puoi aggiungere switch, rimuovere link o subire guasti e la rete convergerà su un modello di inoltro sicuro.
Fatto bene, STP fornisce due risultati che normalmente confliggono:
Spanning Tree Protocol (STP) ha un solo compito: mantenere la ridondanza di Ethernet senza permettere al traffico di girare all’infinito. Lo fa facendo sì che tutti gli switch concordino su un unico insieme “migliore” di link da usare in ogni momento—chiamato spanning tree—e mettendo gli link extra in uno stato di riserva.
STP prima elegge un root bridge, lo switch scelto come punto di riferimento per l’intera rete. Pensalo come “il centro della mappa”. Il root è determinato da un valore di priorità (configurato o di default) e da un identificatore univoco dello switch; vince il più basso.
Ogni switch si chiede: “Qual è il mio miglior percorso verso il root?” STP assegna un path cost a ogni collegamento (i link più veloci di solito hanno costi inferiori). Ogni switch somma i costi lungo i percorsi possibili e sceglie il totale più basso come percorso preferito verso il root.
La porta che uno switch non-root usa per raggiungere il root su quel percorso migliore diventa la sua root port.
Su ogni connessione condivisa tra switch (un “segmento”), STP ha bisogno di esattamente uno switch che inoltri il traffico verso il root. Quella porta inoltrante è la designated port per il segmento. Lo switch che pubblicizza il percorso a costo minore verso il root su quel segmento ottiene il ruolo di designated.
Le porte che non sono scelte né come root port né come designated port vengono messe in blocking (o in stati non-forwarding simili nelle varianti più recenti). Il blocco non rimuove il cavo né elimina la ridondanza: semplicemente impedisce a quella porta di inoltrare i frame Ethernet normali, così non si crea un loop. Se un link attivo fallisce, STP può sbloccare un percorso di riserva e mantenere la connettività.
Rendiamo STP concreto con una piccola rete di quattro switch:
STP comincia scegliendo un unico punto di riferimento: il root bridge. Ogni switch pubblicizza un identificatore (bridge ID) e vince l’ID più basso.
Supponiamo che S1 abbia l’ID più basso. Ora tutti concordano: S1 è il root.
Ogni switch non-root sceglie esattamente una porta come root port: la porta che fornisce il miglior percorso verso S1.
Per ogni segmento, STP sceglie un lato come designated port che inoltra per quel segmento. Qualsiasi porta che non sia root port né designated port diventa blocking.
In questo esempio, il link S3–S4 è dove il loop viene interrotto. Se S3 raggiunge già il root tramite S2, STP può mettere la porta di S3 verso S4 (o la porta di S4 verso S3, a seconda dei tie-break) in blocking.
Risultato: tutti i cavi sono ancora collegati, ma esiste un solo percorso attivo tra due punti—nessun loop.
Se il percorso attivo si interrompe (ad esempio S2–S3 cade), STP rivaluta la topologia. Il link precedentemente bloccato S3–S4 può passare a forwarding, ripristinando la connettività tramite S3 → S4 → S1.
Il cambiamento non è istantaneo; STP richiede tempo per riconvergere e aggiornare lo stato di inoltro senza reintrodurre loop.
Spanning Tree funziona solo se tutti gli switch nella rete concordano sulle stesse regole. Per questo gli standard sono importanti: le reti reali sono spesso multi-vendor, costruite con apparati acquistati in momenti diversi. Senza un protocollo condiviso, la funzione “prevenzione loop” di un vendor potrebbe non capire quella di un altro, trasformando la ridondanza in un outage.
Il protocollo STP tradizionale è definito in IEEE 802.1D. Non serve leggere le clausole per beneficiarne—il punto è che 802.1D dà ai vendor un linguaggio comune su come eleggere un root bridge, calcolare il path cost e decidere quali porte devono inoltrare o bloccare.
Anche quando si passa a varianti più recenti (come RSTP o MSTP), l’aggiornamento è possibile perché il comportamento è standardizzato abbastanza da permettere la coordinazione tra dispositivi.
Gli switch si coordinano usando piccoli frame di controllo chiamati BPDUs (Bridge Protocol Data Units). Considera le BPDUs come i messaggi di saluto di STP: contengono le informazioni necessarie agli switch per costruire una visione condivisa della topologia—chi credono sia il root, quanto è distante (cost), e informazioni temporali.
Poiché le BPDUs vengono scambiate continuamente, STP può reagire quando qualcosa cambia. Se un link si rompe, la conversazione BPDU cambia e gli switch possono riconvergere e aprire un percorso precedentemente bloccato.
Un dettaglio pratico: i vendor spesso usano nomi diversi per le stesse impostazioni. Un parametro come “port cost”, “edge/PortFast” o “bpdu guard” può apparire in menu diversi o essere descritto in modo differente. I concetti di base di STP sono coerenti, ma la terminologia dell’interfaccia no—quindi conviene tradurre le opzioni nel significato che 802.1D intende ottenere.
Lo STP classico (IEEE 802.1D) risolveva i loop, ma poteva essere dolorosamente lento a “guarire” dopo un guasto di link o switch. Il motivo è semplice: STP era prudente. Le porte non passavano subito a forwarding—attraversavano stati temporizzati (blocking → listening → learning → forwarding). Con i timer di default, la riconvergenza poteva richiedere decine di secondi (spesso ~30–50 secondi), abbastanza perché le chiamate vocali cadessero, le applicazioni scadessero o gli utenti pensassero che “la rete è giù”.
Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) mantiene lo stesso obiettivo—inoltro senza loop con ridondanza—ma cambia il modo in cui gli switch raggiungono l’accordo.
Invece di aspettare lunghi timer fissi, RSTP usa un handshake più rapido tra switch per confermare quali porte possono inoltrare in sicurezza. Riconosce anche che alcune porte dovrebbero passare immediatamente:
In parole semplici: RSTP continua a bloccare i link giusti per prevenire loop; semplicemente smette di trattare ogni cambiamento come un evento nel peggiore dei casi.
Con la crescita delle reti, eseguire un solo albero per tutto è diventato limitante—soprattutto con molte VLAN e topologie complesse. Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) consente di creare più istanze di spanning tree e mappare gruppi di VLAN a ciascuna istanza.
Questo permette di:
Il miglioramento principale lungo STP → RSTP → MSTP è coerente: mantenere la ridondanza, prevenire loop e ripristinare l’inoltro più velocemente e in modo più prevedibile.
Il beneficio più sottovalutato di Spanning Tree è come trasforma “cavi e switch extra” in affidabilità prevedibile. Su scala enterprise—molti armadi, molti switch di accesso, cambiamenti continui—la ridondanza Layer 2 può essere un dono o una trappola. STP la rende più probabilmente il primo.
Le grandi reti raramente falliscono perché un singolo link si è scollegato; falliscono perché il recupero è disordinato. STP aiuta fornendo un modo controllato per far reagire la rete ai cambiamenti:
Molte organizzazioni mantengono STP abilitato anche se pensano che la loro topologia sia priva di loop. Il motivo è pragmatico: le persone sbagliano, la documentazione si perde e appaiono percorsi Layer 2 inaspettati. Con STP attivo, un cavo patch messo per errore è più probabile che causi una porta bloccata che un outage dell’intero edificio.
I data center moderni spesso preferiscono fabric leaf–spine routati (Layer 3) o tecnologie multipath Layer 2 specifiche per ottenere larghezza di banda attiva/attiva senza dipendere dalla riconvergenza classica di STP. Detto questo, STP (o varianti come RSTP/MSTP) è ancora ampiamente usato nelle reti campus, nei segmenti edge e come livello di compatibilità dove non è pratico usare solo Layer 3.
Su larga scala, il vero risultato di STP è operativo tanto quanto tecnico: rende la ridondanza gestibile per team ordinari, non solo per specialisti.
STP è semplice nel concetto—prevenire loop Layer 2 mantenendo percorsi di backup—ma alcuni miti persistenti portano persone a disabilitarlo, malconfigurarlo o “ottimizzarlo” fino a causare un outage.
È vero che le reti moderne spesso si affidano a routing Layer 3, MLAG e design overlay che riducono la necessità dello STP classico (IEEE 802.1D). Ma STP (o le sue forme più recenti come RSTP/MSTP) offre ancora una rete di sicurezza ovunque Ethernet possa accidentalmente formare un loop: switch di accesso, reti temporanee per eventi, laboratori, siti branch piccoli e qualsiasi ambiente dove qualcuno potrebbe collegare due porte insieme “solo per provare”.
Disabilitare STP può trasformare un errore di cablaggio innocuo in una tempesta di broadcast che porta giù un’intera VLAN.
Una porta bloccata non è “morta”. È un percorso di standby pre-validato. STP scambia intenzionalmente un po’ di capacità attiva per stabilità: se il link in forwarding fallisce, il link bloccato può diventare nuovo percorso senza che un operatore debba ricollegare manualmente i cavi.
I team a volte cercano di forzare tutti i link in forwarding disattivando STP, appiattendo le VLAN o aggiungendo switch non gestiti. Può sembrare efficiente—fino al primo loop che fonde la rete.
La ridondanza aiuta solo quando è progettata. Aggiungere cross-link extra tra switch senza pianificazione aumenta il numero di scenari di loop possibili e rende il comportamento di STP più difficile da prevedere. Il risultato può essere percorsi di traffico imprevisti, uplink bloccati o riconvergenza più lenta dopo un guasto.
Anche con STP attivo, impostazioni sbagliate possono provocare danni reali:
La conclusione: STP non è solo una casella da spuntare—è un piano di controllo. Trattalo come tale, documenta le intenzioni e convalida le modifiche prima di applicarle su larga scala.
I problemi STP spesso si manifestano come “la rete è lenta” prima che qualcuno capisca che c’è un problema Layer 2. Alcuni controlli mirati possono far risparmiare ore di analisi.
Quando appare un loop Ethernet o instabilità STP, di solito vedrai:
Inizia dalle fondamenta:
Una buona igiene STP è soprattutto processo:
Se vuoi una checklist più ampia per isolare problemi di rete oltre STP, vedi /blog/network-troubleshooting-basics.
STP è un ottimo esempio di “infrastruttura silenziosa” e tende a fallire in modi molto umani: intenti poco chiari, cablaggio non documentato, configurazioni incoerenti e troubleshooting ad-hoc. Un modo pratico per ridurre il rischio è costruire strumenti interni leggeri e runbook attorno alle operazioni STP.
Con Koder.ai, i team possono creare rapidamente dashboard o utility partendo da una chat—per esempio uno strumento che ingerisce gli output degli switch, evidenzia il root bridge corrente, segnala porte bloccate inattese o traccia eventi di topology-change nel tempo. Poiché Koder.ai supporta l’esportazione del codice sorgente e il deploy/hosting di app (con rollback e snapshot), è anche un modo comodo per trasformare la “conoscenza tribale” in un servizio interno mantenuto invece di uno script sparso sul laptop di qualcuno.
Il lavoro di Radia Perlman sullo spanning tree ci ricorda che alcune delle infrastrutture più importanti non sono appariscenti—semplicemente prevengono il caos. Dando a Ethernet un modo pratico per usare link ridondanti senza creare loop, STP ha reso “aggiungi un percorso di backup” un comportamento predefinito sicuro invece di un esperimento rischioso. Quel cambiamento ha permesso reti Layer 2 più grandi e resilienti in aziende, campus e data center.
STP assume che qualcosa andrà storto: un cavo collegato nella porta sbagliata, uno switch che si riavvia, un link che flappa. Invece di sperare che gli operatori non sbaglino, costruisce un sistema che assorbe gli errori e converge comunque su uno stato sicuro. La lezione va oltre il networking: considera i modi di guasto come requisiti prioritari.
Spanning Tree blocca intenzionalmente alcuni link così la rete rimanga stabile. Quella “capacità sprecata” è un compromesso in favore di un comportamento prevedibile. I sistemi ben progettati spesso riservano margine—tempo, controlli extra, guardrail—perché evitare un guasto catastrofico vale più che spremere l’ultimo percento di utilizzo.
STP funziona perché ogni switch segue le stesse regole distribuite e scambia piccoli messaggi di controllo per concordare una topologia senza cicli. Non serve un operatore che decida manualmente cosa spegnere a ogni cambiamento. La conclusione: quando molti componenti devono cooperare, investi in protocolli e default che rendano il comportamento sicuro anche il comportamento più semplice.
Se ricordi solo poche cose, tienile a mente:
Questa mentalità—più che una singola funzione—spiega perché spanning tree è diventato un essenziale silenzioso.
Se vuoi altre guide ai fondamenti di rete accessibili, esplora /blog.
Un loop di livello 2 si verifica quando gli switch hanno due o più percorsi attivi tra gli stessi segmenti, creando un ciclo. Poiché i frame Ethernet non hanno un limite di hop a livello 2, il traffico floodato (broadcast e unknown unicast) può circolare indefinitamente e moltiplicarsi, sovraccaricando i link e le CPU degli switch.
La ridondanza introduce percorsi alternativi, ma senza coordinamento gli switch possono inoltrare su tutti i percorsi contemporaneamente. Questo crea un loop in cui i frame floodati vengono replicati ripetutamente, provocando tempeste di broadcast e apprendimento MAC instabile — spesso portando a outage di rete a causa di un singolo cavo patch aggiunto per errore.
STP mantiene i link ridondanti fisicamente connessi ma disabilita logicamente alcune porte in modo che la topologia attiva formi un albero senza cicli. Se un percorso attivo fallisce, STP può promuovere una porta precedentemente bloccata a forwarding per ripristinare la connettività.
STP elegge un root bridge come punto di riferimento per l'intero dominio Layer 2. Lo switch con il bridge ID più basso (priority + identificatore univoco) diventa root; scegliere come root uno switch di core/distribuzione previsto aiuta a rendere i percorsi del traffico più prevedibili.
Ogni switch non-root seleziona una root port: la porta con il minor path cost totale verso il root. Il path cost si basa sulla velocità del link (i link più veloci hanno di solito costi inferiori); in caso di parità si usano tie-breaker come gli ID per decidere in modo deterministico.
Per ogni segmento tra switch, STP seleziona una designated port che inoltra il traffico per quel segmento (la parte che pubblicizza il percorso migliore verso il root). Qualsiasi porta che non sia root port né designated port diventa blocking/discarding, ed è così che STP interrompe i loop.
Significa che la porta non inoltra il traffico utente normale, quindi non può partecipare a un loop. Il collegamento resta attivo e può scambiare traffico di controllo STP; se la topologia cambia (per esempio per un guasto), quella porta bloccata può essere promossa a forwarding come nuovo percorso attivo.
Le BPDUs (Bridge Protocol Data Units) sono frame di controllo STP che gli switch si scambiano per condividere informazioni di topologia: chi pensano sia il root, il costo del percorso verso di esso e dettagli temporali. Scambiando BPDUs continuamente, gli switch possono rilevare cambiamenti e riconvergere su una topologia sicura senza cicli.
Lo STP classico (IEEE 802.1D) può impiegare decine di secondi per riconvergere perché usa timer conservativi e stati di porta sequenziali. RSTP (802.1w) accelera il processo con handshake più rapidi e transizioni immediate per certe porte (come le porte edge/PortFast), riducendo i tempi di inattività dopo un guasto.
Una checklist pratica:
Per diagnostiche più ampie oltre STP, vedi /blog/network-troubleshooting-basics.