# Progetto di reti locali/Spanning Tree Protocol

Progetto di reti locali
Copertina Tutti i moduli · Sviluppo
    CopertinaProgetto di reti locali/Copertina
* Nozioni di base sulle LAN
** Introduzione alle Local Area NetworkProgetto di reti locali/Introduzione alle Local Area Network
** EthernetProgetto di reti locali/Ethernet
** Repeater e bridgeProgetto di reti locali/Repeater e bridge
** Evoluzioni di EthernetProgetto di reti locali/Evoluzioni di Ethernet
** Funzionalità avanzate sulle reti EthernetProgetto di reti locali/Funzionalità avanzate sulle reti Ethernet
* Albero ricoprente
** Spanning Tree ProtocolProgetto di reti locali/Spanning Tree Protocol
** Rapid Spanning Tree ProtocolProgetto di reti locali/Rapid Spanning Tree Protocol
* Standard aggiuntivi per le LAN
** Qualità del servizio nelle LAN IEEE 802Progetto di reti locali/Qualità del servizio nelle LAN IEEE 802
** Link aggregation – IEEE 802.3adProgetto di reti locali/Link aggregation – IEEE 802.3ad
** IGMP snoopingProgetto di reti locali/IGMP snooping
* Configurazione e progettazione avanzate delle LAN
** Virtual LANProgetto di reti locali/Virtual LAN
** Ridondanza e bilanciamento del carico a livello 3 nelle LANProgetto di reti locali/Ridondanza e bilanciamento del carico a livello 3 nelle LAN
** Il livello rete nelle LANProgetto di reti locali/Il livello rete nelle LAN
* Argomenti aggiuntivi
** Introduzione alle Storage Area NetworkProgetto di reti locali/Introduzione alle Storage Area Network
Modifica il sommario

## Il problema dei cicli

Se la rete presenta un anello logico in topologia, alcune trame possono iniziare a girare all'infinito in una moltiplicazione a catena all'interno del ciclo:
* trame broadcast/multicast: vengono sempre propagate su tutte le porte, provocando un broadcast storm;
* trame unicast inviate a una stazione ancora non presente nel filtering database o non esistente: vengono mandate in flooding.
Inoltre, i bridge nel ciclo possono avere filtering database inconsistenti, cioè la entry nel filtering database relativa alla stazione mittente cambia la porta ogni volta che arriva una replica della trama su una porta diversa, facendo credere al bridge che la trama arrivi dalla stazione stessa che si è spostata.

## Algoritmo di spanning tree

L'algoritmo di spanning tree consente di eliminare gli anelli logici dalla topologia fisica della rete, disattivando dei link per trasformare una topologia magliata (grafo) in un albero chiamato albero ricoprente, la cui radice è uno dei bridge chiamato root bridge.
Ogni link è caratterizzato da un costo basato sulla velocità del link: dato un root bridge, possono essere costruiti più alberi ricoprenti che connettono tutti i bridge tra loro, ma l'algoritmo di spanning tree sceglie l'albero ricoprente composto dagli archi a costo minore.

### Parametri

* Bridge Identifier: identifica il bridge in modo univoco e contiene:
** priorità del bridge: può essere impostata liberamente (valore predefinito = 32768);
** indirizzo MAC del bridge: è scelto tra gli indirizzi MAC delle sue porte da un algoritmo specifico del produttore e non può essere modificato;
* Port Identifier: identifica la porta del bridge e contiene:
* priorità della porta: può essere impostata liberamente (valore predefinito = 128);
* numero della porta: in teoria un bridge non può avere più di 256 porte → in pratica si può anche utilizzare il campo della priorità della porta se necessario;
* Root Path Cost: è pari alla somma dei costi dei link, selezionati dall'algoritmo di spanning tree, attraversati per raggiungere il root bridge (il costo di attraversamento di un bridge è nullo).

### Criteri

L'albero ricoprente si può determinare con i seguenti criteri.

#### Root bridge

Un root bridge è la radice dell'albero ricoprente: tutte le trame che vanno da uno dei suoi sottoalberi a un altro devono attraversare il root bridge.
Si seleziona come root bridge il bridge con il Bridge Identifier più piccolo: la radice dell'albero ricoprente sarà quindi il bridge con la priorità più bassa, o a parità di priorità quello con l'indirizzo MAC più basso.

#### Porta root

* Criteri per la selezione di una porta root per il bridge indicato dalla freccia.
* Percorso a costo minimo.
* Bridge ID remoto più piccolo.
* Port ID remoto più piccolo.
* Port ID locale più piccolo.
Una porta root è la porta responsabile della connessione al root bridge: invia le trame verso il root bridge e riceve le trame dal root bridge.
* Si determina il costo di ogni percorso possibile dal bridge alla radice. Da questi, si sceglie quello con il costo più piccolo (un percorso a costo minimo). La porta connessa a quel percorso è quindi la porta root del bridge.
* Quando più percorsi a partire da un bridge sono percorsi a costo minimo verso la radice, il bridge utilizza il bridge vicino con il Bridge Identifier più piccolo per inoltrare le trame alla radice. La porta root è così quella connessa al bridge con il Bridge Identifier più basso.
* Quando due bridge sono connessi con più cavi, più porte su un singolo bridge sono candidate per la porta root. In questo caso, si utilizza il percorso che passa attraverso la porta sul bridge vicino che ha il Port Identifier più piccolo.
* In una particolare configurazione con un hub dove i Port Identifier remoti sono uguali, si utilizza il percorso che passa attraverso la porta sul bridge stesso che ha il Port Identifier più piccolo.

#### Porta designata

* Criteri per la selezione di una porta designata per il link indicato dalla freccia.
* Percorso a costo minimo.
* Bridge ID locale più piccolo.
* Port ID locale più piccolo.
Una porta designata è la porta responsabile di servire il link: invia i frame alle foglie e riceve i frame dalle foglie.
* Si determina il costo di ogni percorso possibile da ogni bridge connesso al link alla radice. Da questi, si sceglie quello con il costo più piccolo (un percorso a costo minimo). La porta connessa al link del bridge che conduce a quel percorso è quindi la porta designata del link.
* Quando più bridge su un link conducono a un percorso a costo minimo verso la radice, il link utilizza il bridge con il Bridge Identifier più piccolo per inoltrare le trame alla radice. La porta che connette quel bridge al link è la porta designata per il link.
* Quando un bridge è connesso a un link con più cavi, più porte su un singolo bridge sono candidate per la porta designata. In questo caso, si utilizza il percorso che passa attraverso la porta sul bridge stesso che ha il Port Identifier più piccolo.

#### Porta bloccata

Una porta bloccata non invia mai i frame sul link e scarta tutti i frame ricevuti (eccetto le Configuration BPDU).
Qualsiasi porta attiva che non sia né una porta root né una porta designata è una porta bloccata.

## Messaggi BPDU

I criteri qui sopra descrivono un modo di determinare quale albero ricoprente sarà calcolato dall'algoritmo, ma le regole così come scritte richiedono la conoscenza dell'intera rete. I bridge devono determinare il root bridge e calcolare i ruoli delle porte (root, designata o bloccata) con le sole informazioni di cui dispongono.
Affinché i bridge possano scambiarsi informazioni sui Bridge Identifier e sui Root Path Cost, lo Spanning Tree Protocol (STP), standardizzato come IEEE 802.1D (1990), definisce dei messaggi chiamati BPDU.

### Formato delle BPDU

Le BPDU hanno il seguente formato:
Formato della Configuration BPDU (35 byte) nello STP. :
| 1 | 7 | 8 | 16 | 24 | 32 |
| Protocol ID (0) | Protocol ID (0) | Protocol ID (0) | Protocol ID (0) | Version (0) | BPDU Type (0) |
| TC | 000000 | TCA | Root Priority | Root Priority | |
| Root MAC Address ||||||
| | | | Root Path Cost | Root Path Cost | Root Path Cost |
| | | | Bridge Priority | Bridge Priority | |
| Bridge MAC Address ||||||
| | | | Port Priority | Port Number | Message Age |
| | | | Max Age | Max Age | Hello Time |
| | | | Forward Delay | Forward Delay | |
Formato della Topology Change Notification BPDU (4 byte). :
| 16 | 24 | 32 |
| Protocol ID (0) | Version (0) | BPDU Type (0x80) |
dove i campi sono:
* campo Protocol Identifier (2 byte): specifica il protocollo IEEE 802.1D (valore 0);
* campo Version (1 byte): distingue lo Spanning Tree Protocol (valore 0) dal Rapid Spanning Tree Protocol (valore 2);
* campo BPDU Type (1 byte): specifica il tipo di BPDU:
** Configuration BPDU (CBPDU) (valore 0): utilizzata per il calcolo dell'albero ricoprente, cioè per determinare il root bridge e gli stati delle porte: #Ingresso di un nuovo bridge;
** Topology Change Notification BPDU (TCN BPDU) (valore 0x80): utilizzata per annunciare i cambiamenti nella topologia della rete al fine di aggiornare le entry nei filtering database: #Annuncio di cambiamenti di topologia;
* flag Topology Change (TC) (1 bit): impostato dal root bridge per informare tutti i bridge che è avvenuto un cambiamento nella rete;
* flag Topology Change Acknowledgement (TCA) (1 bit): impostato dal root bridge per informare il bridge che ha rilevato il cambiamento che la sua Topology Change Notification BPDU è stata ricevuta;
* campo Root Identifier (8 byte): specifica il Bridge Identifier del root bridge della rete:
** campo Root Priority (2 byte): contiene la priorità del root bridge;
** campo Root MAC Address (6 byte): contiene l'indirizzo MAC del root bridge;
* campo Bridge Identifier (8 byte): specifica il Bridge Identifier del bridge che sta propagando la Configuration BPDU:
** campo Bridge Priority (2 byte): contiene la priorità del bridge;
** campo Bridge MAC Address (6 byte): contiene l'indirizzo MAC del bridge;
* campo Root Path Cost (4 byte): contiene il costo del percorso per raggiungere il root bridge, visto dal bridge che sta propagando la Configuration BPDU;
* campo Port Identifier (2 byte): specifica il Port Identifier della porta su cui il bridge sta propagando la Configuration BPDU:
** campo Port Priority (1 byte): contiene la priorità della porta;
** campo Port Number (1 byte): contiene il numero della porta;
* campo Message Age (2 byte): valore, inizializzato a 0, che ogni volta che la Configuration BPDU attraversa un bridge viene incrementato per il tempo di transito attraverso il bridge;
* campo Max Age (2 byte, valore predefinito = 20 s): se il Message Age raggiunge il valore Max Age, la Configuration BPDU ricevuta non è più valida;
* campo Hello Time (2 byte, valore predefinito = 2 s): specifica ogni quanto tempo il root bridge genera la Configuration BPDU;
* campo Forward Delay (2 byte, valore predefinito = 15 s): specifica il tempo di attesa prima di forzare la transizione di una porta ad un altro stato.

### Generazione e propagazione delle BPDU

Solo il root bridge può generare Configuration BPDU: tutti gli altri bridge si limitano a propagare le Configuration BPDU ricevute su tutte le loro porte designate. Le porte root sono quelle che ricevono le Configuration BPDU migliori, cioè con valore Message Age più basso = Root Path Cost più basso. Le porte bloccate non inviano mai le Configuration BPDU ma rimangono in ascolto delle Configuration BPDU in arrivo.
Invece le Topology Change Notification BPDU possono essere generate da qualsiasi bridge non root, e vengono propagate sempre sulle porte root.
Quando un bridge genera/propaga una trama BPDU, utilizza l'indirizzo MAC univoco della porta stessa come indirizzo sorgente, e l'indirizzo multicast 01:80:C2:00:00:00 dello STP come indirizzo di destinazione:
| 6 byte | 6 byte | 2 byte | 1 byte | 1 byte | 1 byte | | 4 byte |
| 01:80:C2:00:00:00 (multicast) | indirizzo bridge sorgente (unicast) | ... | 0x42 | 0x42 | 0x03 | BPDU | ... |
| indirizzo MAC di destinazione | indirizzo MAC sorgente | length | DSAP | SSAP | CTRL | payload | FCS |

## Comportamento dinamico
### Stati delle porte
#### Disabled

    Una porta spenta perché nessun link è connesso alla porta.

#### Blocking

    Una porta che provocherebbe un ciclo se fosse attiva. Nessuna trama è inviata o ricevuta su una porta in stato di blocking (le Configuration BPDU vengono comunque ricevute in stato di blocking), ma essa potrebbe andare in stato di forwarding se gli altri link in uso si guastano e l'algoritmo di spanning tree determina che la porta può passare allo stato di forwarding.

#### Listening

    Il bridge elabora le Configuration BPDU e attende eventuali nuove informazioni che farebbero ritornare la porta allo stato di blocking. Non popola il filtering database e non inoltra trame.

#### Learning

    Mentre la porta non inoltra ancora le trame, il bridge apprende gli indirizzi sorgente dalle trame ricevute e li aggiunge al filtering database. Popola il filtering database, ma non invia le trame.

#### Forwarding

    Una porta che sta ricevendo e inviando dei dati. Lo STP continua comunque a monitorare le Configuration BPDU in arrivo, così la porta potrebbe ritornare allo stato di blocking per impedire un ciclo.
Ruoli e stati delle porte nello STP. :
| stato porta | ruolo porta | riceve trame? | riceve e elabora CBPDU? | genera o propaga CBPDU? | aggiorna filtering database? | inoltra trame? | genera o propaga TCN BPDU? |
| disabled | bloccata | no | no | no | no | no | no |
| blocking | bloccata | sì | sì | no | no | no | no |
| listening | (in transizione) | sì | sì | sì | no | no | no |
| learning | designata | sì | sì | sì | sì | no | no |
| learning | root | sì | sì | no | sì | no | sì |
| forwarding | designata | sì | sì | sì | sì | sì | no |
| forwarding | root | sì | sì | no | sì | sì | sì |

### Ingresso di un nuovo bridge

Quando un nuovo bridge viene connesso a una rete di livello data-link, assumendo che abbia un Bridge Identifier più alto di quello del root bridge corrente della rete:
* all'inizio il bridge, senza sapere (ancora) nulla sul resto della rete, assume di essere il root bridge: imposta tutte le sue porte come designate (stato di listening) e inizia a generare delle Configuration BPDU su di esse, dicendo di essere il root bridge;
* gli altri bridge ricevono le Configuration BPDU generate dal nuovo bridge e confrontano il Bridge Identifier del nuovo bridge con quello del root bridge corrente della rete, quindi le scartano;
* periodicamente il root bridge della rete genera delle Configuration BPDU, che gli altri bridge ricevono dalle loro porte root e propagano attraverso le loro porte designate;
* quando il nuovo bridge riceve una Configuration BPDU dal root bridge della rete, apprende di non essere il root bridge perché esiste un altro bridge avente un Bridge Identifier più basso del suo, quindi smette di generare Configuration BPDU e imposta la porta da cui ha ricevuto la Configuration BPDU del root bridge come porta root;
* anche il nuovo bridge inizia a propagare le Configuration BPDU, stavolta relative al root bridge della rete, su tutte le sue altre porte (designate), mentre continua a ricevere le Configuration BPDU propagate dagli altri bridge;
* quando il nuovo bridge riceve su una porta designata una Configuration BPDU "migliore", in base ai criteri per la selezione della porta designata, rispetto alla Configuration BPDU che sta propagando su tale porta, quest'ultima smette di propagare le Configuration BPDU e diventa bloccata (stato di blocking);
* dopo un tempo pari al Forward Delay, le porte rimaste designate e la porta root passano dallo stato di listening a quello di learning: il bridge inizia a popolare il filtering database, per evitare che il bridge cominci subito a mandare le trame in flooding sovraccaricando la rete;
* dopo un tempo pari al Forward Delay, le porte designate e la porta root passano dallo stato di learning a quello di forwarding: il bridge può propagare anche le trame normali su tali porte.

## Cambiamenti nella topologia della rete
### Ricalcolo dell'albero ricoprente

Quando si verifica un cambiamento di topologia, lo STP è in grado di rilevare il cambiamento di topologia, grazie alla generazione periodica delle Configuration BPDU da parte del root bridge, e di continuare a garantire l'assenza di anelli in topologia, ricalcolando se necessario l'albero ricoprente, vale a dire il root bridge e gli stati delle porte.

#### Guasto di un link

Quando un link (appartenente all'albero ricoprente corrente) si guasta:
* le Configuration BPDU che il root bridge genera non riescono più a raggiungere l'altra porzione della rete: in particolare, la porta designata del link guasto non invia più Configuration BPDU;
* l'ultima Configuration BPDU ascoltata dalla porta bloccata al di là del link "invecchia" nel bridge stesso, cioè il suo Message Age viene incrementato con il passare del tempo;
* quando il Message Age raggiunge il valore di Max Age, l'ultima Configuration BPDU ascoltata scade e il bridge riparte da capo rieleggendosi root bridge: reimposta tutte le porte come designate, e inizia a generare Configuration BPDU dicendo di essere il root bridge;
* lo STP continua in un modo analogo al caso precedentemente trattato relativo all'ingresso di un nuovo bridge:
** se esiste un link non appartenente all'albero ricoprente che collega le due porzioni di rete, la porta bloccata connessa a quel link alla fine diventerà porta root in stato di forwarding, e il link entrerà a far parte dell'albero ricoprente;
** altrimenti, se le due porzioni di rete non possono più essere connesse tra loro, in ogni porzione di rete verrà eletto un root bridge.

#### Inserimento di un nuovo link

Quando viene inserito un nuovo link, le porte a cui il nuovo link è connesso diventano designate in stato di listening, e iniziano a propagare le Configuration BPDU generate dal root bridge della rete → arrivano delle nuove Configuration BPDU attraverso il nuovo link:
* se il link ha un costo sufficientemente basso, il bridge connesso al link inizia a ricevere da una porta non root delle Configuration BPDU aventi un Root Path Cost minore rispetto a quello delle Configuration BPDU ricevute dalla porta root → la porta root viene aggiornata in modo che il root bridge sia raggiungibile attraverso il percorso migliore (in base ai criteri per la selezione della porta root), così come le porte designate e bloccate sono eventualmente aggiornate di conseguenza;
* se il link ha un costo troppo alto, le Configuration BPDU che lo attraversano hanno un Root Path Cost troppo alto → una delle due porte connesse al nuovo link diventa bloccata e l'altra rimane designata (in base ai criteri per la selezione della porta designata).

### Annuncio di cambiamenti di topologia

Quando in seguito a un cambiamento di topologia lo STP modifica l'albero ricoprente cambiando gli stati delle porte, esso non modifica le entry nei filtering database dei bridge per riflettere i cambiamenti → le entry possono non essere aggiornate: ad esempio, le trame verso una certa destinazione potrebbero continuare ad essere mandate su una porta diventata bloccata, fino a quando la entry relativa a quella destinazione non scade perché il suo ageing time è andato a 0 (nel caso peggiore: 5 minuti!).
Lo STP prevede un meccanismo per velocizzare la convergenza della rete per quanto riguarda il filtering database quando è rilevato un cambiamento di topologia:
* il bridge che ha rilevato il cambiamento di topologia genera una Topology Change Notification BPDU attraverso la sua porta root verso il root bridge per annunciare il cambiamento di topologia;
* i bridge attraversati inoltrano immediatamente la Topology Change Notification BPDU attraverso le loro porte root;
* il root bridge genera in risposta una Configuration BPDU con i flag Topology Change e Topology Change Acknowledgement impostati a 1, che dopo essere stata inoltrata indietro dai bridge attraversati verrà ricevuta dal bridge che ha rilevato il cambiamento di topologia;
* il root bridge genera su tutte le sue porte designate una Configuration BPDU con il flag Topology Change impostato;
* ogni bridge, quando riceve la Configuration BPDU:
** scarta tutte le entry nel suo filtering database aventi ageing time inferiori al Forward Delay;
** propaga a sua volta la Configuration BPDU su tutte le sue porte designate (mantenendo il flag Topology Change impostato);
* la rete funziona temporaneamente in una condizione sub-ottimale perché vengono mandate più trame in flooding, fino a quando i bridge non popolano di nuovo i loro filtering database con i nuovi percorsi tramite gli algoritmi di apprendimento.

## Problemi
### Prestazioni

La filosofia dello STP è "nega sempre, consenti solo quando sicuro": quando avviene un cambiamento di topologia, le trame non vengono inoltrate finché non si è sicuri che il transitorio è esaurito, cioè non ci sono cicli e la rete è in uno stato coerente, anche introducendo dei tempi di attesa lunghi a scapito della rapidità di convergenza e della raggiungibilità di alcune stazioni.
Supponendo di rispettare le tempistiche consigliate dallo standard, cioè:
* siano adottati i valori temporali consigliati dallo standard: Max Age = 20 s, Hello Time = 2 s, Forward Delay = 15 s;
* il tempo di transito attraverso ogni bridge da parte di una BPDU non superi il TransitDelay = HelloTime ÷ 2 = 1 s;
non si possono collegare più di 7 bridge in cascata tra due sistemi terminali affinché una Configuration BPDU possa attraversare l'intera rete due volte entro il Forward Delay: se venisse messo un ottavo bridge in cascata, infatti, nel caso peggiore le porte del nuovo bridge, autoelettosi root bridge, passerebbero dallo stato di listening a quello di forwarding prima che la Configuration BPDU proveniente dal root bridge all'altra estremità della rete giunga in tempo al nuovo bridge:
Con l'introduzione dello stato di learning, dopo il guasto di un link la rete impiega approssimativamente 50 secondi per convergere a uno stato coerente:
* 20 s (Max Age): richiesti affinché l'ultima Configuration BPDU ascoltata scada e il guasto sia rilevato;
* 15 s (Forward Delay): richiesti per la transizione della porta dallo stato di listening a quello di learning;
* 15 s (Forward Delay): richiesti per la transizione della porta dallo stato di learning a quello di forwarding.
Inoltre, il raggiungimento di uno stato coerente nella rete non implica necessariamente la fine del disservizio sperimento dall'utente: infatti il guasto si può ripercuotere anche a livello applicativo, molto sensibile alle perdite di connettività oltre a una certa soglia:
* i sistemi per la gestione delle basi di dati potrebbero iniziare delle lunghe procedure di recupero dai guasti;
* le applicazioni multimediali di rete che generano del traffico anelastico (come le applicazioni VoIP) soffrono molto delle variazioni di ritardo.
Si potrebbe provare a personalizzare i valori relativi ai parametri temporali per aumentare la rapidità di convergenza ed ampliare il diametro di bridge massimo, ma quest'operazione è sconsigliata:
* se non si fa attenzione si rischia di ridurre la reattività della rete ai cambiamenti di topologia e di intaccare le funzionalità della rete;
* a prima vista sembra sufficiente operare solo sul root bridge poiché questi valori vengono tutti propagati dal root bridge all'intera rete, ma in realtà se il root bridge cambia il nuovo root bridge deve annunciare gli stessi valori → è necessario di fatto aggiornare questi parametri su tutti i bridge.
Spesso lo STP viene disabilitato sulle porte edge, cioè le porte collegate direttamente agli host finali, per alleviare i disservizi sperimentati dall'utente:
* a causa dei ritardi di transizione delle porte, un PC che si connette alla rete rimarrebbe inizialmente isolato per un tempo pari a due Forward Delay;
* la connessione di un PC rappresenta un cambiamento di topologia → la pulizia delle entry vecchie scatenata dall'annuncio del cambiamento di topologia aumenterebbe considerevolmente il numero di trame inviate in flooding nella rete.
Alle porte edge tuttavia vanno collegati esclusivamente gli host, altrimenti si potrebbero creare dei cicli nella rete → alcuni fornitori non permettono ciò: ad esempio, il meccanismo PortFast proprietario di Cisco raggiunge lo stesso obiettivo senza disabilitare lo STP sulle porte edge, essendo in grado di farle passare immediatamente allo stato di forwarding e di rilevare eventuali cicli su di esse (ovvero due porte edge collegate tra loro da un filo diretto).

### Scalabilità

Dato un root bridge, possono essere costruiti più alberi ricoprenti che connettono tutti i bridge tra loro, ma l'algoritmo di spanning tree sceglie l'albero ricoprente composto dagli archi a costo minore. In questo modo, i percorsi sono ottimizzati solo rispetto alla radice dell'albero:
* i link disabilitati sono completamente inutilizzati, ma qualcuno comunque deve pagare per tenerli attivi come link secondari per la tolleranza ai guasti;
* non è possibile il bilanciamento del carico per distribuire il traffico su più link paralleli → i link appartenenti all'albero ricoprente selezionato devono sopportare anche il carico del traffico che, se non ci fosse lo STP, prenderebbe un percorso più breve passando per i link disabilitati:
Una rete IP è invece in grado di organizzare meglio il traffico: l'albero ricoprente non è unico nell'intera rete, ma ogni sorgente può calcolare il proprio albero e inviare il traffico sul percorso più breve garantendo un maggiore bilanciamento del carico dei link.
Le Virtual LAN (VLAN) risolvono questo problema instaurando degli alberi ricoprenti multipli.

### Link unidirezionali

Lo STP ipotizza che ciascun link sia bidirezionale: se un link si guasta, non è più possibile inviare trame in nessuna delle due direzioni. In realtà i cavi in fibra ottica sono unidirezionali → per collegare due nodi sono necessari due cavi in fibra ottica, uno per la comunicazione in una direzione e l'altro per la comunicazione nella direzione opposta, e un guasto su uno dei due cavi interrompe solo il traffico in una direzione.
Se uno dei due link unidirezionali si guasta, potrebbe nascere un ciclo sull'altro link nonostante lo STP: le Configuration BPDU sono propagate in modo unidirezionale dalla radice alle foglie → se il percorso di propagazione diretto si rompe, il bridge all'altra estremità non riceve più le Configuration BPDU del root bridge da quel link, quindi sposta la porta root su un altro link e, assumendo che non ci sia nessuno su quel link, imposta la porta come designata creando un ciclo:
Unidirectional Link Detection (UDLD) è un protocollo proprietario di Cisco in grado di rilevare la presenza di un guasto su un link unidirezionale grazie a una sorta di "ping", e di disabilitare la porta (stato "error disabled") invece di eleggerla come designata.

### Posizionamento del root bridge

* Configurazione ottimale.
* Configurazione da evitare.
La posizione del root bridge ha un pesante impatto nella rete:
* il traffico da una parte all'altra della rete deve passare per il root bridge → le prestazioni, in termini di throughput aggregato e larghezza di banda delle porte, del bridge selezionato come root bridge devono essere sufficienti per sopportare una grande quantità di traffico;
* è preferibile una topologia a stella, dove il root bridge è il centro stella → ciascun link collega un solo bridge al root bridge:
** bilanciamento del carico dei link più equilibrato: il link non deve sostenere il traffico proveniente da altri bridge;
** maggiore tolleranza ai guasti: un guasto del link interessa solo la connettività di un bridge;
* i server e i datacenter vanno posizionati vicino al root bridge al fine di ridurre la latenza della comunicazione dati;
→ è necessario personalizzare a un valore molto basso la priorità del bridge che deve essere il root bridge, in modo da non rischiare che un altro bridge sia eletto root bridge.
È importante anche la posizione del bridge di backup, pensato per entrare in gioco in caso di guasto di un link primario o del root bridge primario:
* guasto di un link primario: la configurazione ottimale è una topologia a stella ridondante composta da link secondari, in cui ogni bridge è collegato al bridge di backup da un link secondario;
* guasto del root bridge primario: è necessario personalizzare anche la priorità del root bridge di backup a un valore appena più alto della priorità del root bridge primario, in modo da forzare quel bridge a essere eletto root bridge in caso di guasto.

### Sicurezza

Lo STP non ha dei meccanismi di sicurezza incorporati contro attacchi dall'esterno.

#### Elezione del bridge dell'utente come root bridge

Un utente può collegare alla rete un bridge con una priorità molto bassa forzandolo a diventare il nuovo root bridge e cambiando l'albero ricoprente della rete. La funzione BPDU Guard proprietaria di Cisco permette alle porte edge di propagare le sole Configuration BPDU provenienti dall'interno della rete, rifiutando quelle ricevute dall'esterno (la porta va in stato "error disabled").

#### Rate limit su broadcast storm

Quasi tutti i bridge professionali hanno qualche forma di controllo dei broadcast storm in grado di limitare la quantità di traffico broadcast sulle porte scartando il traffico in eccesso oltre a una certa soglia, ma questi misuratori di traffico non riescono a distinguere tra le trame di un broadcast storm e trame broadcast inviate dalle stazioni → rischiano di filtrare del traffico broadcast legittimo, e un broadcast storm è più difficile da individuare.

#### Collegamento di bridge senza STP

Un singolo bridge privo di STP o con STP disabilitato può iniziare a pompare traffico broadcast nella rete se collegato in modo che si formi un ciclo fuori dal controllo dello STP: sono esempi il collegamento di una porta del bridge direttamente a un'altra dello stesso bridge, o il collegamento del bridge dell'utente a due bridge interni della rete con due link ridondanti.

#### Domini di STP multipli

Talvolta si vuole collegare due diversi domini di STP, ognuno con il proprio albero ricoprente, a uno stesso canale condiviso (ad es. due provider con domini di STP diversi nello stesso datacenter). La funzione BPDU Filter proprietaria di Cisco disabilita l'invio e la ricezione di Configuration BPDU sulle porte alle periferie dei domini, per tenere divisi gli alberi ricoprenti.

## Note

* ↑ In realtà l'algoritmo di spanning tree blocca le porte, non i link: {{subst:vedi|#Stati delle porte}}
* ↑ Si prega di fare attenzione al fatto che il traffico che si sposta all'interno dello stesso sottoalbero non attraversa il root bridge.
* 1 2 3 4 I campi temporali sono espressi in unità di 256$^{esimi}$ di secondo (circa 4 ms).
* ↑ Il bridge continua a generare la Topology Change Notification BPDU ogni Hello Time, finché non riceve l'acknowledge.
* ↑ Il root bridge continua a generare in risposta la Configuration BPDU di acknowledgement per Max Age + Forward Delay.
* ↑ Quando questo vincolo fu stabilito, lo stato di learning non era ancora stato introdotto e le porte passavano direttamente dallo stato di listening a quello di forwarding.
* ↑ Esattamente il valore minimo per il Forward Delay sarebbe pari a 14 s, ma è stata prevista una tolleranza di 1 s.