Progetto di reti locali/Rapid Spanning Tree Protocol

Il Rapid Spanning Tree Protocol (RSTP), standardizzato come IEEE 802.1w (2001), è caratterizzato da una maggiore rapidità di convergenza rispetto allo STP in termini di:

• ricalcolo dell'albero ricoprente
• aggiornamento dei filtering database

Ruoli e stati delle porte

Il RSTP definisce nuovi ruoli e stati delle porte:

• stato discarding: la porta non inoltra trame e scarta quelle ricevute (eccetto le Configuration BPDU), unificando gli stati di disabled, blocking e listening;
• ruolo alternate: la porta, in stato di discarding, è collegata allo stesso link di una porta designata di un altro bridge, rappresentando un rimpiazzamento rapido per la porta root;
• ruolo backup: la porta, in stato di discarding, è collegata allo stesso link di una porta designata dello stesso bridge, rappresentando un rimpiazzamento rapido per la porta designata;
• ruolo edge: alla porta si possono collegare solo host, mirando a ridurre, rispetto allo STP classico, i disservizi sperimentati dagli utenti nel collegare i propri host alla rete.

Ruoli e stati delle porte nel RSTP.

stato porta	ruolo porta	riceve trame?	riceve e elabora CBPDU?	genera e propaga CBPDU?	aggiorna filtering database?	inoltra trame?
discarding	alternate	sì	sì	no	no	no
	backup	sì	sì	no	no	no
	designata	sì	sì	sì	no	no
learning	designata	sì	sì	sì	sì	no
	root	sì	sì	no	sì	no
forwarding	designata	sì	sì	sì	sì	sì
	root	sì	sì	no	sì	sì
	edge	sì	sì	no	sì	sì

Formato della Configuration BPDU

La Configuration BPDU ha il seguente formato:

Formato della Configuration BPDU (35 byte) nel RSTP.

1	2	4	6	7	8	12	16	24	32
Protocol ID (0)								Version (2)	BPDU Type (2)
TC	P	R	S	A	TCA	Root Priority	STP Instance
Root MAC Address
						Root Path Cost
						Bridge Priority	STP Instance
Bridge MAC Address
						Port Priority		Port Number	Message Age
						Max Age			Hello Time
						Forward Delay

dove ci sono alcuni cambiamenti rispetto alle BPDU dello STP classico:

• campo Version (1 byte): identifica il RSTP come numero di versione 2 (nello STP era 0);
• campo BPDU Type (1 byte): identifica la Configuration BPDU sempre come tipo 2 (nello STP era 0), dato che non esistono più le Topology Change Notification BPDU;
• 6 nuovi flag: controllano il meccanismo proposal/agreement:
  • flag Proposal (P) e Agreement (A) (1 bit ciascuno): specificano se il ruolo della porta è stato proposto da un bridge (P = 1) o accettato dall'altro bridge (A = 1);
  • 2 flag nel campo Role (R) (2 bit): codificano il ruolo della porta proposto o accettato (00 = sconosciuto, 01 = alternate/backup, 10 = root, 11 = designata);
  • 2 flag nel campo State (S) (2 bit): specificano se la porta per cui è stato proposto o accettato il ruolo si trova nello stato di learning (10) o di forwarding (01);
• campi Root Identifier e Bridge Identifier (8 byte ciascuno): il RSTP include le specifiche tecniche di IEEE 802.1t (2001) che cambiano il formato del Bridge Identifier:
  • campo Bridge Priority (4 bit, valore predefinito = 8);
  • campo STP Instance (12 bit, valore predefinito = 0): utilizzato nelle Virtual LAN per abilitare più istanze di protocollo entro la stessa rete fisica: Progetto di reti locali/Virtual LAN#PVST;
  • campo Bridge MAC Address (6 byte): invariato rispetto a IEEE 802.1D-1998;
• campo Root Path Cost (4 byte): il RSTP include le specifiche tecniche di IEEE 802.1t (2001) che cambiano i valori consigliati per il Port Path Cost includendo nuove velocità delle porte (fino a 10 Tb/s);
• campi Max Age e Forward Delay (2 byte ciascuno): sono completamente inutilizzati nel RSTP, ma sono stati mantenuti per ragioni di compatibilità.

Cambiamenti nella topologia della rete

Ricalcolo dell'albero ricoprente

Il RSTP è caratterizzato da una maggiore rapidità di convergenza della topologia rispetto allo STP classico: infatti si passa da 50 secondi a meno di 1 secondo (ordine dei 10 ms circa) se, com'era ormai la norma quando il RSTP fu standardizzato, in presenza di soli link punto-punto full duplex (quindi senza hub).

Rilevamento del guasto di un link

Quando si verifica il guasto di un link, il suo rilevamento da parte del RSTP è più rapido rispetto allo STP classico grazie a una gestione più efficiente delle BPDU.

I bridge non root non si limitano a propagare le BPDU generate dal root bridge: ogni bridge genera a ogni Hello Time (predefinito: 2 s) una BPDU, con il root bridge corrente come Root Identifier, anche se non ha ricevuto la BPDU dal root bridge. Se non sono state ricevute BPDU da 3 periodi di Hello Time, la BPDU corrente è dichiarata obsoleta e si assume che un guasto si è verificato sul link a cui la porta root è connessa.

Questo invecchiamento delle informazioni più rapido è inutile sulle reti moderne:

• nelle reti più vecchie con gli hub, un bridge non può rilevare a livello fisico un guasto tra l'hub e un altro bridge → l'unico modo per rilevarlo è accorgersi che i messaggi BPDU "keep-alive" hanno smesso di essere ricevuti;
• nelle reti più recenti che sono commutate pure, un bridge può rilevare immediatamente il guasto di un link a livello fisico senza aspettare per 3 periodi di Hello Time.

Una volta che un bridge ha rilevato il guasto di un link, inizia a generare le proprie BPDU → ogni bridge vicino, non appena riceve sulla sua porta root una BPDU dal bridge che sta pretendendo di essere il root bridge, invece di scartarla perché è peggiore di quella corrente, accetta la nuova BPDU dimenticando quella memorizzata in precedenza, perché significa che qualcosa è andato storto sul suo percorso verso il root bridge. A questo punto:

• se il suo Bridge Identifier è peggiore di quello nella BPDU, il bridge inizia a generare delle BPDU sulle sue porte designate con il nuovo Root Identifier;
• se il suo Bridge Identifier è migliore di quello nella BPDU, il bridge inizia a generare le proprie BPDU pretendendo di essere il root bridge.

Recupero dal guasto di un link

Una volta rilevato un guasto, alcune porte possono passare direttamente allo stato di forwarding senza transitare per lo stato di learning.

Porte alternate

In caso di guasto della porta root, la porta alternate fornisce un percorso alternativo tra il bridge e il root bridge:

• La porta alternate rappresenta un rimpiazzamento rapido per la porta root.
• 
• 

Porte di backup

In caso di guasto della porta designata, la porta di backup fornisce un percorso alternativo tra il bridge e il link:

• La porta di backup rappresenta un rimpiazzamento rapido per la porta designata.
• 
• 

Inserimento di un nuovo link

La sequenza proposal/agreement è un algoritmo per la sincronizzazione rapida sul ruolo delle porte tra due bridge.

Quando si inserisce un nuovo link tra due bridge:

1. ciascuno dei due bridge mette in stato di discarding la sua porta connessa al nuovo link, così come tutte le sue eventuali altre porte root e designate connesse su altri link, per prevenire il formarsi di eventuali cicli durante il transitorio;
2. ciascuno dei due bridge propone la sua porta come designata del link inviando una BPDU sul nuovo link con il flag Proposal impostato;
3. il bridge peggiore accetta la proposta dell'altro bridge inviando in risposta una BPDU con il flag Agreement impostato, e mette la sua porta nel ruolo appropriato (root, alternate o backup) secondo i criteri dell'algoritmo di spanning tree;
4. il bridge migliore riceve la BPDU di accettazione e mette la sua porta come designata del link;
5. ciascuno dei due bridge ripete la sequenza per le altre porte che all'inizio aveva messo in stato di discarding.

La cooperazione tra i due bridge tramite l'invio di BPDU è più rapida rispetto al meccanismo basato su timer dello STP classico, e più efficiente in quanto non blocca tutta la rete per un certo tempo ma di volta in volta solo l'intorno di un bridge. Il nuovo link dev'essere full duplex affinché le BPDU possano essere scambiate in entrambi i sensi: la BPDU di proposta in una direzione e la BPDU di accettazione nell'altra.

Aggiornamento dei filtering database

Rilevamento di cambiamenti di topologia

Il RSTP mira ad essere meno invasivo rispetto allo STP classico per quanto riguarda l'aggiornamento dei filtering database in seguito a cambiamenti di topologia: infatti evita di pulire i filtering database dalle vecchie entry, con il conseguente aumento considerevole del traffico mandato in flooding, quando non è necessario.

Passaggio allo stato di discarding

Il passaggio di una porta allo stato di discarding non scatena l'aggiornamento dei filtering database:

• se il link rimosso non apparteneva a un ciclo, cioè non esistono dei percorsi alternativi, allora le stazioni nell'altro segmento di rete non sono più raggiungibili e le entry ad esse associate non sono più valide, ma ciò non è considerato un problema da risolvere immediatamente: se una trama viene inviata a una di quelle stazioni, essa arriverà al bridge che era collegato al link rimosso e verrà scartata, fino a quando la entry non scadrà naturalmente e verrà cancellata dal bridge senza dover toccare le altre entry;
• se il link rimosso apparteneva a un ciclo, cioè esiste un percorso alternativo attraverso una porta in stato di discarding, allora sarà quest'ultima porta a scatenare l'aggiornamento dei filtering database nel passare allo stato di forwarding secondo i meccanismi del RSTP.

Passaggio allo stato di forwarding

Solo il passaggio di una porta non edge allo stato di forwarding scatena l'aggiornamento dei filtering database:

• se il nuovo link non crea un ciclo, allora non sarebbe necessario scatenare l'aggiornamento dei filtering database perché nessuna stazione diventa irraggiungibile, ma si ricorda che un bridge non ha la conoscenza della topologia globale della rete;
• se il nuovo link crea un ciclo, allora il passaggio allo stato di forwarding della porta comporta il passaggio allo stato di discarding di un'altra porta lungo il ciclo secondo i meccanismi del RSTP → le stazioni che si raggiungevano attraverso quella porta sono ora raggiungibili per un altro percorso, e occorre perciò aggiornare le entry ad esse associate.

Annuncio di cambiamenti di topologia

Quando un bridge rileva un cambiamento di topologia che richiede l'aggiornamento dei filtering database:

1. il bridge che ha rilevato il cambiamento di topologia genera su tutte le sue porte root e designate una BPDU con il flag Topology Change impostato;
2. ogni bridge, quando riceve la BPDU:
   1. scarta tutte le entry nel suo filtering database associate a tutte le sue porte root e designate, tranne quella da cui ha ricevuto la BPDU;
   2. propaga la BPDU su tutte le sue porte root e designate, tranne quella da cui ha ricevuto la BPDU.

Comportamento delle porte edge

Quando un host si connette a una porta edge, la porta diventa subito designata e passa allo stato di forwarding senza transitare per lo stato di learning → non è più necessario aspettare 30 secondi (2 volte il Forward Delay) prima di avere la porta pienamente operativa.

Inoltre, le porte edge non scatenano mai l'aggiornamento dei filtering database né al passaggio allo stato di forwarding (connessione di host) né al passaggio allo stato di discarding (disconnessione di host) → l'utente non sperimenta più un rallentamento della rete a causa dell'aumento di traffico inviato in flooding, e la prima trama broadcast che l'host invierà aggiornerà i filtering database secondo i normali algoritmi di apprendimento dei bridge.

Una porta edge si tiene comunque in ascolto di BPDU in arrivo da eventuali bridge collegati erroneamente ad essa, in modo da essere pronta ad uscire immediatamente dal ruolo di edge e assumere uno degli altri ruoli per proteggere la rete da possibili cicli.

Problemi

Coesistenza di STP e RSTP

Se viene introdotto nella rete un bridge che non supporta il RSTP, alla ricezione di Configuration BPDU con Type pari a 0 sono in grado di passare automaticamente in modalità STP, ma ciò ha degli effetti collaterali:

• a causa di un singolo bridge che non supporta il RSTP, tutta la rete va in modalità STP e vengono così persi i tempi di convergenza rapidi;
• se il singolo bridge che non supporta il RSTP si guasta o viene scollegato dalla rete, gli altri bridge continuano a operare in modalità STP, ed è necessario praticare esplicita configurazione manuale su ogni singolo bridge.

Un bridge può essere configurato in modo da operare in modalità RSTP su alcune porte, e in modalità STP su altre porte → la rete è suddivisa in due porzioni che operano con versioni diverse del protocollo di spanning tree. Ciò tuttavia può portare all'instabilità della rete a causa di cicli transitori dovuti al fatto che la porzione RSTP attiva l'inoltro delle trame dati prima della porzione STP.

Per una coesistenza senza problemi di bridge RSTP e non RSTP nella stessa rete, occorre utilizzare il Multiple Spanning Tree Protocol, standardizzato come IEEE 802.1s (2002): le porzioni della rete che funzionano con RSTP e quelle che funzionano con STP sono separate in domini diversi.

Affidabilità del livello fisico

Il RSTP funziona perfettamente quando i link a livello fisico sono affidabili. Se invece un link si attiva e si disattiva frequentemente a causa di un connettore sporco (le fibre ottiche sono piuttosto sensibili), il RSTP riconfigura la rete a ogni cambiamento di stato del link → la rete rimarrà in uno stato transitorio instabile per la maggior parte del tempo, a causa della troppo rapida reattività del RSTP.

Il meccanismo di "antiflapping" proprietario di Cisco mette la porta in stato "error disabled" quando rileva il flapping di un link.