Informazioni sul protocollo Rapid Spanning Tree Protocol (802.1w)

Introduzione

In questo documento vengono fornite informazioni sulle migliorie apportate da RSTP al precedente standard 802.1D.

Introduzione

Lo standard 802.1D Spanning Tree Protocol (STP) è stato progettato quando ripristinare una connettività interrotta nel giro di un minuto poteva essere considerato accettabile. Con l'avvento dello switching di layer 3 in ambienti LAN, sono ora disponibili soluzioni alternative in cui protocolli come Open Shortest Path First (OSPF) e Enhanced Interior Gateway Routing Protocol (EIGRP) sono in grado di fornire un percorso alternativo in meno tempo.

Cisco ha migliorato la specifica 802.1D originale in modo che Uplink Fast, Backbone Fast e Port Fast velocizzino i tempi di convergenza di una rete bridged. Lo svantaggio è che questi meccanismi sono proprietari e richiedono un'ulteriore configurazione.

Il protocollo Rapid Spanning Tree Protocol (RSTP; IEEE 802.1w) può essere considerato un'evoluzione dello standard 802.1D più che un protocollo radicalmente nuovo. La terminologia 802.1D rimane essenzialmente la stessa. La maggior parte dei parametri è rimasta invariata, quindi gli utenti che hanno familiarità con lo standard 802.1D potranno configurare rapidamente anche il nuovo protocollo. Nella maggior parte dei casi, RSTP offre prestazioni migliori rispetto alle estensioni proprietarie di Cisco senza configurazione aggiuntiva. È possibile tornare dallo standard 802.1w allo standard 802.1D in modo da poter comunicare con i bridge preesistenti configurando le singole porte. In questo modo si rinuncia però ai vantaggi introdotti con il nuovo standard.

La nuova versione dello standard 802.1D, IEEE 802.1D-2004, include gli standard IEEE 802.1t-2001 e IEEE 802.1w.

Supporto RSTP nei Catalyst Switch

In questa tabella viene mostrato il supporto RSTP per alcune famiglie di dispositivi Catalyst Switch e il software minimo richiesto.

Piattaforma Catalyst	MST con RSTP	RPVST+ (o PVRST+)
Catalyst 2900 XL/3500 XL	Non disponibile.	Non disponibile.
Catalyst 2940	12.1(20)EA2	12.1(20)EA2
Catalyst 2950/2955/3550	12.1(9)EA1	12.1(13)EA1
Catalyst 2970/3750	12.1(14)EA1	12.1(14)EA1
Catalyst 3560	12.1(19)EA1	12.1(19)EA1
Catalyst 3750 Metro	12.1(14)AX	12.1(14)AX
Catalyst 2948G-L3/4908G-L3	Non disponibile.	Non disponibile.
Catalyst 4000/4500 (Cisco IOS®)	12.1(12c)EW	12.1(19)EW
Catalyst 6000/6500 (Cisco IOS)	12.1(11b)EX, 12.1(13)E, 12.2(14)SX	12.1(13)E
Catalyst 8500	Non disponibile.	Non disponibile.

Nuovi stati e ruoli delle porte

Nello standard 802.1D la porta può trovarsi in uno dei seguenti cinque stati:

• disabled

• listening (ascolto)

• learning (apprendimento)

• blocking (blocco)

• inoltro

Per ulteriori informazioni sugli stati delle porte, vedere la tabella nella sezione Stati delle porte di questo documento.

Lo stato della porta, ad esempio blocking o forwarding, e il ruolo che svolge nella topologia attiva (ad esempio porta root, designata etc.) possono sovrapporsi. Ad esempio, da un punto di vista operativo, non c'è differenza tra una porta in stato blocking e una porta in stato listening. Entrambe ignorano i frame e non apprendono gli indirizzi MAC. La vera differenza sta nel ruolo assegnato dallo Spanning Tree. Si può ad esempio presumere che una porta in ascolto sia una porta designata o una porta root e stia per passare allo stato forwarding. Ma, una volta nello stato forwarding, non è più possibile stabilire se la porta era una porta root o una porta designata. Ecco perché dobbiamo considerare superata questa terminologia basata sullo stato. Per risolvere questo problema, il protocollo RSTP distingue tra ruolo e stato di una porta.

Stati delle porte

Il protocollo RSTP prevede solo tre stati delle porte che corrispondono a tre possibili stati operativi. Gli stati disabled, blocking e listening previsti dallo standard 802.1D sono raggruppati nello standard 802.1w in un unico stato, discarding (ignora).

Stato della porta STP (802.1D)	Stato della porta RSTP (802.1w)	La porta è inclusa nella topologia attiva?	La porta sta apprendendo gli indirizzi MAC?
Disabled	Discarding	No	No
Blocking	Discarding	No	No
Listening	Discarding	Sì	No
Learning	Learning	Sì	Sì
Inoltro	Inoltro	Sì	Sì

Ruoli delle porte

Il ruolo è ora una variabile assegnata a una determinata porta. I ruoli di porta root e porta designata rimangono, mentre il ruolo di porta in blocco è suddiviso tra i ruoli di porta di backup e porta alternativa. L'algoritmo Spanning Tree Algorithm (STA) determina il ruolo di una porta in base alle Bridge Protocol Data Unit (BPDU). Per semplificare le cose, ricordare che è sempre possibile confrontare le BPDU e decidere quale delle due è più utile. La decisione si basa sul valore memorizzato nella BPDU e a volte sulla porta che le riceve. Ciò considerato, nel prosieguo della sezione spiegheremo come gestire nella pratica i ruoli delle porte.

Ruoli delle porte root

• La porta che riceve la BPDU migliore su un bridge è la porta root. Questa è la porta più vicina al root bridge in termini di costi del percorso. L'algoritmo STA sceglie un singolo root bridge su tutta la rete bridged (per VLAN). Il root bridge invia BPDU più utili di quelle inviate da qualsiasi altro bridge. Il root bridge è l'unico bridge nella rete che non ha una porta root. Tutti gli altri bridge ricevono le BPDU su almeno una porta.

  

Ruolo della porta designata

• Una porta si dice designata se può inviare la migliore BPDU sul segmento a cui è connessa. I bridge 802.1D collegano tra loro segmenti diversi, ad esempio i segmenti Ethernet, per creare un dominio bridge. Su un dato segmento, può esserci solo un percorso verso il root bridge. Se ce ne sono due, nella rete si è creato un loop di bridge. Tutti i bridge connessi a un determinato segmento restano in ascolto delle BPDU degli altri bridge e scelgono di comune accordo il bridge che invia la migliore BPDU come bridge designato per quel segmento. La porta corrispondente di tale bridge è la porta designata di quel segmento.

  

Ruoli della porta alternativa e della porta di backup

• Questi due ruoli corrispondono allo stato blocking nello standard 802.1D. Per porta bloccata si intende una porta che non è una porta designata né una porta root. Una porta bloccata riceve una BPDU più utile di quella che invia sul suo segmento. Ricordare che, per rimanere bloccata, è necessario che una porta riceva le BPDU. Il protocollo RSTP ha introdotto questi due ruoli a tale scopo.

• Una porta alternativa riceve BPDU più utili da un altro bridge ed è una porta bloccata. Lo schema seguente ne dà una rappresentazione grafica:

  

• Una porta di backup riceve BPDU più utili dallo stesso bridge su cui si trova ed è una porta bloccata. Lo schema seguente ne dà una rappresentazione grafica:

  

Questa distinzione è già presente nello standard 802.1D ed è il modo in cui essenzialmente funziona Cisco UplinkFast. Una porta alternativa fornisce un percorso alternativo al root bridge e può quindi sostituire una porta root in caso di errore. Al contrario, una porta di backup fornisce una connettività ridondante allo stesso segmento e non può garantire una connettività alternativa al root bridge. Pertanto, viene esclusa dal gruppo di uplink.

Di conseguenza, RSTP calcola la topologia finale dello Spanning Tree con gli stessi criteri dello standard 802.1D. Non vi è alcuna differenza nel modo in cui le diverse priorità di bridge e porta vengono usate. Nell'implementazione Cisco, la designazione blocking viene usata per indicare lo stato discarding. Nelle versioni CatOS 7.1 e successive vengono usati ancora gli stati listening e learning. Ciò fornisce ancora più informazioni su una porta rispetto a quanto richiesto dallo standard IEEE. Tuttavia, la nuova funzionalità ora presenta una differenza tra il ruolo che il protocollo stabilisce per una porta e il suo stato corrente. Ad esempio, ora è valido che una porta sia allo stesso tempo designata e bloccata. Sebbene ciò avvenga in genere per periodi molto brevi, significa che questa porta è in uno stato transitorio verso lo stato forwarding designato.

Nuovo formato delle BPDU

Il protocollo RSTP introduce solo pochi cambiamenti per il formato BPDU. Nello standard 802.1D sono definiti solo due flag, Topology Change (TC) e TC Acknowledgment (TCA). Tuttavia, il protocollo RSTP usa tutti e sei i bit rimanenti del byte di flag per:

• Codificare il ruolo e lo stato della porta originati dalla BPDU

• Gestire il meccanismo di proposta e accordo

Visualizzazione completa dei diagrammi Cisco BPDU, IEEE BPDU e BPDU

Per una risoluzione più elevata dell'immagine, vedere i diagrammi Cisco BPDU, IEEE BPDU e BPDU.

Nota: il bit 0 (modifica della topologia) è il bit meno significativo.

Un'altra differenza importante è che le RSTP BPDU sono ora di tipo 2, versione 2. Ne deriva che i bridge preesistenti devono ignorare la nuova BPDU. Questa proprietà facilita il rilevamento di bridge preesistenti da parte di un bridge 802.1w.

Nuova gestione delle BPDU

Invio delle BPDU definito dal parametro hello-time

Le BPDU vengono inviate ad ogni hello-time e non sono più semplicemente inoltrate. Nello standard 802.1D, un bridge non root genera le BPDU solo quando ne riceve una sulla porta root. Infatti, un bridge trasmette le BPDU più di quanto ne generi. Lo stesso non può dirsi per lo standard 802.1w. Un bridge invia una BPDU con le informazioni correnti all'intervallo stabilito dal parametro <hello-time> (2 secondi per impostazione predefinita), anche se non ne riceve alcuna dal root bridge.

Durata inferiore della validità temporale delle informazioni

Su una data porta, se non si ricevono "hello" per tre volte consecutive, le informazioni del protocollo perdono immediatamente validità, ovvero il loro periodo di validità massima, max_age, scade. Nel nuovo standard le BPDU vengono ora usate come meccanismo keep-alive tra i bridge. Se un bridge non riceve tre BDPU consecutive, considera come persa la connettività al root bridge vicino o designato. La minore durata del periodo di validità delle informazione permette di rilevare gli errori tempestivamente. Se un bridge non riesce a ricevere una BPDU da un vicino, è certo che la connessione con tale bridge è persa. Nello standard 802.1D il comportamento è diverso, in quanto non si può sapere il punto esatto del percorso al root bridge in cui si è verificato il problema.

Nota: se gli errori riguardano collegamenti fisici, vengono rilevati ancora più rapidamente.

Accettazione delle BPDU inferiori

Questo concetto è alla base del motore BackboneFast. Il comitato IEEE 802.1w ha incorporato un meccanismo simile nel protocollo RSTP. Quando un bridge riceve informazioni inferiori dal bridge designato o dal root bridge, le accetta immediatamente e sostituisce le informazioni precedentemente memorizzate.

Poiché il Bridge C sa ancora che il root bridge è attivo e funzionante, invia immediatamente una BPDU al Bridge B con informazioni sul root bridge. Di conseguenza, il Bridge B non invia le proprie BPDU e accetta la porta che si connette al Bridge C come nuova porta root.

Passaggio rapido allo stato forwarding

La funzionalità più importante introdotta dallo standard 802.1w è il passaggio rapido allo stato forwarding. Prima di assegnare a una porta lo stato forwarding, il precedente algoritmo STA attendeva passivamente che la rete convergesse. Per ottenere una convergenza più rapidamente, occorreva regolare i parametri predefiniti (i timer ritardo di inoltro e max_age) mettendo spesso a repentaglio la stabilità della rete. Il nuovo protocollo RSTP (Rapid STP) è in grado di confermare attivamente il passaggio sicuro di una porta allo stato forwarding senza dover fare affidamento su alcuna configurazione di timer. Ora esiste un vero meccanismo di feedback tra i bridge conformi all'RSTP. Per ottenere una convergenza rapida su una porta, il protocollo si basa su due nuove variabili: porte edge e tipo di collegamento.

Porte edge

Il concetto di porta edge è già noto agli utenti Spanning Tree di Cisco, in quanto corrisponde sostanzialmente alla funzione PortFast. Tutte le porte collegate direttamente alle postazioni terminali non possono creare loop di bridge nella rete. Pertanto, la porta edge passa direttamente allo stato forwarding e ignora le fasi di ascolto e apprendimento. Né le porte edge né le porte abilitate PortFast generano modifiche alla topologia quando il collegamento viene attivato. Una porta edge che riceve una BPDU perde immediatamente lo stato di porta edge e diventa una normale porta Spanning Tree. A questo punto, esiste un valore configurato dall'utente e un valore operativo per lo stato della porta edge. Nelle implementazioni Cisco, la parola chiave PortFast viene usata per la configurazione delle porte edge. Questo rende più semplice passare al protocollo RSTP.

Tipo di collegamento

Il protocollo RSTP può assicurare un rapido passaggio allo stato forwarding solo sulle porte edge e sui collegamenti point-to-point. Il tipo di collegamento viene ricavato automaticamente dalla modalità duplex di una porta. Una porta che funziona in modalità full-duplex è considerata una porta point-to-point, mentre una porta half-duplex è considerata una porta condivisa per impostazione predefinita. Questo valore automatico del tipo di collegamento può essere ignorato da una configurazione esplicita. Nelle reti di switch moderne, la maggior parte dei collegamenti opera in modalità full-duplex e il protocollo RSTP tratta i collegamenti come collegamenti point-to-point. Ciò rende possibile un rapido passaggio delle porte allo stato forwarding.

Convergenza con 802.1D

Nel diagramma viene illustrato come lo standard 802.1D gestisce un nuovo collegamento aggiunto a una rete bridged:

In questo scenario, viene aggiunto un collegamento tra il root bridge e il Bridge A. Supponiamo che esista già una connessione indiretta tra il Bridge A e il root bridge (tramite C - D nel diagramma). L'algoritmo STA blocca una porta e disabilita il loop di bridge. Innanzitutto, quando diventano attive, entrambe le porte sul collegamento tra il root bridge e il Bridge A vengono messe nello stato listening. Il Bridge A è ora in grado di restare direttamente in ascolto del root bridge. Inoltre, propaga immediatamente le proprie BPDU alle porte designate, verso le diramazioni della struttura ad albero. Non appena i Bridge B e C ricevono le nuove informazioni superiori dal Bridge A, trasmettono immediatamente le informazioni alle diramazioni. In pochi secondi, il Bridge D riceve una BPDU dal root bridge e blocca immediatamente la porta P1.

Lo Spanning Tree è molto efficiente nel calcolare la nuova topologia della rete. L'unico problema è che, prima di passare allo stato forwarding, sul collegamento tra il root bridge e il Bridge A deve trascorrere il doppio del tempo stabilito per il ritardo di inoltro. Ciò significa un'interruzione del traffico di 30 secondi (le parti A, B e C della rete sono completamente isolate), in quanto l'algoritmo 8021.D non ha un meccanismo di feedback per comunicare in modo chiaro e in pochi secondi dove la rete sta convergendo.

Convergenza con 802.1w

Vediamo ora come il protocollo RSTP gestisce una situazione simile. Ricordare che la topologia finale equivale esattamente a quella calcolata dallo standard 802.1D (ovvero una porta bloccata nello stesso punto di prima). Sono cambiati solo i passaggi necessari per arrivare a questa topologia.

Entrambe le porte sul collegamento tra lo Switch A e il root bridge vengono bloccate non appena si attivano. Fino a questo momento, tutto si svolge come in un ambiente solo 802.1D. Tuttavia, in questa fase, avviene una negoziazione tra lo switch A e il root bridge. Non appena lo Switch A riceve la BPDU dal root bridge, blocca le porte non edge designate. Questa operazione è chiamata sincronizzazione. Successivamente, il Bridge A autorizza esplicitamente il root bridge a mettere la sua porta in stato forwarding. Nel diagramma viene illustrato il risultato di questo processo sulla rete. Il collegamento tra lo Switch A e il root bridge è bloccato ed entrambi i bridge si scambiano le BPDU.

Quando lo Switch A blocca le porte non edge designate, il collegamento tra lo Switch A e il root bridge viene portato in stato forwarding e si ha la seguente situazione:

Non è ancora possibile avere un loop. Invece di bloccarsi prima dello Switch A, la rete si blocca ora dopo lo Switch A. Tuttavia, il potenziale loop di bridge viene interrotto in una posizione diversa. Questa interruzione si ripercuote lungo tutta la struttura ad albero insieme alle nuove BPDU originate dal root bridge tramite lo Switch A. In questa fase, le porte appena bloccate sullo Switch A negoziano una rapida transizione allo stato forwarding con le porte adiacenti sullo Switch B e sullo Switch C ed entrambi avviano un'operazione di sincronizzazione. Oltre alla porta root indirizzata allo Switch A, lo Switch B ha solo porte edge designate. Pertanto, non deve bloccare alcuna porta per autorizzare lo Switch A a passare allo stato forwarding. Analogamente, lo Switch C deve solo bloccare la porta designata verso D. Si arriva quindi allo stato mostrato in questo diagramma:

Ricordare che la topologia finale è esattamente la stessa dello standard 802.1D, ossia la porta P1 verso D deve essere bloccata. La topologia di rete finale si realizza quindi nel tempo necessario per trasmettere le nuove BPDU alla struttura ad albero. Nessun timer è coinvolto in questa convergenza rapida. L'unico nuovo meccanismo introdotto dall'RSTP è la conferma che uno switch può inviare sulla sua nuova porta root al fine di autorizzare il passaggio immediato allo stato forwarding e ignorare le fasi di ascolto e apprendimento che sono lunghe il doppio del ritardo di inoltro. Per beneficiare di una convergenza rapida, l'amministratore deve solo ricordare quanto segue:

• La negoziazione tra bridge è possibile solo quando i bridge sono connessi tramite collegamenti point-to-point (ovvero collegamenti full-duplex a meno che la configurazione delle porte non indichi esplicitamente altro).

• Le porte edge svolgono un ruolo ancora più importante ora che nello standard 802.1D la funzionalità PortFast è abilitata sulle porte. Ad esempio, se l'amministratore di rete non riesce a configurare correttamente le porte edge sullo Switch B, la loro connettività sarà influenzata dal collegamento tra lo Switch A e il root bridge che diventa attivo.

Sequenza proposta/accordo

Quando l'algoritmo STA seleziona una porta come designata, lo standard 802.1D attende ancora per il doppio del tempo indicato in <forward delay> (2x15 secondi per impostazione predefinita) prima di passare allo stato forwarding. Nel protocollo RSTP, questa condizione corrisponde a una porta con un ruolo designato e lo stato blocking. Nei diagrammi che seguono viene illustrato in dettaglio come ottenere questo passaggio rapido. Si supponga di creare un nuovo collegamento tra il root bridge e lo Switch A. Entrambe le porte su questo collegamento sono in stato blocking finché non ricevono una BPDU dalla loro controparte.

Quando una porta designata si trova nello stato discarding o learning (e solo in questi casi), imposta il bit di proposta sulle BPDU inviate. Questo è ciò che accade per la porta p0 del root bridge, come mostrato nel passaggio 1 del diagramma precedente. Poiché lo Switch A riceve informazioni superiori, sa immediatamente che p1 è la nuova porta root. Lo Switch A avvia quindi una sincronizzazione per verificare che tutte le sue porte siano sincronizzate alle nuove informazioni. Una porta è sincronizzata se soddisfa uno dei seguenti criteri:

• La porta è nello stato blocking, equivalente allo stato discarding in una topologia stabile.

• La porta è una porta edge.

Per illustrare l'effetto della sincronizzazione sui diversi tipi di porte, supponiamo che esista una porta alternativa p2, una porta di inoltro designata p3 e una porta edge p4 sullo Switch A. Notare che le porte p2 e p4 soddisfano già questi criteri. Per essere sincronizzato (vedere il passaggio 2 del diagramma precedente), lo Switch A deve solo bloccare la porta p3 e portarla in stato discarding. Ora che tutte le sue porte sono sincronizzate, lo Switch A può sbloccare la porta root p1 appena selezionata e inviare un messaggio di accordo per rispondere al root bridge (vedere il passaggio 3). Questo messaggio è una copia della BPDU di proposta, con il bit di accordo impostato al posto del bit di proposta. In questo modo la porta p0 sa esattamente a quale proposta corrisponde l'accordo ricevuto.

Dopo aver ricevuto l'accordo, la porta p0 può passare immediatamente allo stato forwarding. Ciò è raffigurato nel passaggio 4 della figura precedente. Dopo la sincronizzazione, la porta p3 rimane nello stato discarding designato. Nel passaggio 4, la porta si trova esattamente nella stessa situazione della porta p0 nel passaggio 1. Quindi invia una proposta allo switch vicino e tenta di passare rapidamente allo stato forwarding.

• Il meccanismo di proposta e accordo è molto veloce, in quanto non si basa su alcun timer. Questa serie di handshake si propaga rapidamente verso il perimetro della rete e ripristina rapidamente la connettività dopo una modifica alla topologia.

• Se una porta designata in stato discarding non riceve un accordo dopo aver inviato una proposta, passa lentamente allo stato forwarding e torna alla sequenza di ascolto e apprendimento tipica dello standard 802.1D. Ciò può verificarsi se il bridge remoto non comprende le RSTP BPDU o se la porta del bridge remoto è bloccata.

• Cisco ha introdotto un miglioramento del meccanismo di sincronizzazione che consente a un bridge di mettere in stato discarding solo la sua precedente porta root durante la sincronizzazione. Un descrizione dettagliata di questo meccanismo non rientra nell'ambito di questo documento. Tuttavia, si può presumere che tale meccanismo venga invocato nella maggior parte dei casi di riconvergenza. Lo scenario descritto nella sezione Convergenza con 802.1w di questo documento è estremamente efficiente, poiché solo le porte sul percorso verso la porta finale bloccata vengono temporaneamente confuse.

UplinkFast

Un altro meccanismo per il passaggio immediato allo stato forwarding e incluso nel protocollo RSTP è simile all'estensione UplinkFast proprietaria di Cisco. Fondamentalmente, quando un bridge perde la sua porta root, è in grado di mettere la migliore porta alternativa direttamente in modalità forwarding (l'aspetto di una nuova porta root è sempre gestito dall'RSTP). La selezione di una porta alternativa come nuova porta root genera una modifica nella topologia. Nello standard 802.1w, il meccanismo di modifica della topologia cancella le opportune voci nelle tabelle CAM (Content Addressable Memory) del bridge upstream. Ciò elimina la necessità del processo di generazione multicast fittizio di UplinkFast.

UplinkFast non deve essere configurato ulteriormente perché il meccanismo è incluso in modo nativo e abilitato automaticamente nell'RSTP.

Nuovi meccanismi di modifica della topologia

Quando un bridge 802.1D rileva una modifica della topologia, usa un meccanismo affidabile per avvisare anzitutto il root bridge. Lo schema seguente ne dà una rappresentazione grafica:

Quando il root bridge è stato avvisato di una modifica alla topologia della rete, imposta un flag TC sulle BPDU inviate, che vengono quindi inoltrate a tutti i bridge della rete. Quando un bridge riceve una BPDU con il bit di flag TC impostato, riduce il tempo di validità della tabella di bridging ai secondi del ritardo di inoltro. In questo modo si garantisce un aggiornamento relativamente veloce delle informazioni obsolete. Questo meccanismo di modifica della topologia è stato completamente modificato nel protocollo RSTP. Sia il rilevamento di una modifica alla topologia che la sua propagazione attraverso la rete sono stati aggiornati.

Rilevamento delle modifiche alla topologia

Nel protocollo RSTP, solo le porte non edge che passano nello stato forwarding causano una modifica della topologia. Ciò significa che la perdita di connettività non è più considerata una modifica della topologia, a differenza di quanto avviene nello standard 802.1D (ovvero, una porta che diventa bloccata non genera più un flag TC). Quando un bridge RSTP rileva una modifica della topologia, si verifica quanto segue:

• Avvia il timer TC While con un valore pari al doppio del valore di hello-time per tutte le porte non edge designate e la porta root, se necessario.

• Elimina gli indirizzi MAC associati a tutte queste porte.

Nota: finché il timer TC While è in esecuzione su una porta, sulle BPDU inviate da tale porta il bit TC risulta impostato. Le BPDU vengono inviate anche sulla porta root mentre il timer è attivo.

Propagazione delle modifiche alla topologia

Quando un bridge riceve una BPDU con il bit TC impostato da un bridge vicino, si verifica quanto segue:

• Cancella gli indirizzi MAC appresi su tutte le sue porte, tranne quella che riceve la modifica della topologia.

• Avvia il timer TC While e invia le BPDU con il bit TC impostato a tutte le porte designate e alla porta root (il protocollo RSTP non utilizza più la TCN BPDU specificata, a meno che non sia necessario avvisare un bridge preesistente).

In questo modo, il TCN si diffonde molto rapidamente su tutta la rete. La propagazione del TC è ora un processo che avviene in un solo passaggio. In effetti, chi ha effettuato la modifica della topologia invia queste informazioni a tutta la rete, al contrario di quanto accadeva nello standard 802.1D dove l'invio delle informazioni era prerogativa del solo root bridge. Questo meccanismo è molto più veloce dell'equivalente nello standard 802.1D. Non è necessario attendere che il root bridge venga avvisato né mantenere lo stato di modifica della topologia per l'intera rete per il tempo definito dal parametro <max age plus forward delay> (secondi).

In pochi secondi, o con una serie di più hello-time, la maggior parte delle voci nelle tabelle CAM viene aggiornata sull'intera rete (VLAN). Questo approccio può comportare un flooding temporaneo, ma elimina anche le informazioni potenzialmente obsolete che potrebbero impedire il rapido ripristino della connettività.

Compatibilità con 802.1D

Il protocollo RSTP è in grado di interagire con i protocolli STP esistenti. Tuttavia, è importante ricordare che, quando si interagisce con i bridge STP preesistenti, i vantaggi intrinseci della convergenza rapida dello standard 802.1w andranno persi.

Ogni porta gestisce una variabile che definisce il protocollo da eseguire sul segmento corrispondente. Quando la porta si attiva, parte un timer di ritardo migrazione impostato a tre secondi. Durante questo lasso di tempo, la modalità STP o RSTP al momento associata alla porta viene bloccata. Non appena il timer di ritardo migrazione finisce, la porta si adatta alla modalità corrispondente alla successiva BPDU ricevuta. Se la porta modifica la modalità operativa come risultato di una BPDU ricevuta, il ritardo migrazione viene riavviato. Ciò limita la frequenza con cui la modalità potrebbe essere modificata.

Ad esempio, supponiamo che i Bridge A e B nella figura precedente eseguano entrambi il protocollo RSTP, con lo Switch A designato per il segmento. Un Bridge C con protocollo STP viene introdotto su questo collegamento. Poiché i bridge 802.1D ignorano le RSTP BPDU e le eliminano, il bridge C ritiene che non ci siano altri bridge sul segmento e inizia a inviare le BPDU inferiori in formato 802.1D. Lo Switch A riceve queste BPDU e, dopo un massimo di due hello-time, passa alla modalità 802.1D solo su quella porta. Di conseguenza, C ora comprende le BPDU dello Switch A e accetta A come bridge designato per quel segmento.

Tenere presente, in questo particolare caso, che se il Bridge C viene rimosso, il Bridge A esegue la modalità STP su quella porta anche se potrebbe funzionare in modo più efficiente in modalità RSTP con il suo unico vicino B. Ciò accade perché il Bridge A non sa che il Bridge C è stato rimosso dal segmento. In questo particolare e raro caso, è necessario l'intervento dell'utente per riavviare manualmente il rilevamento del protocollo della porta.

Quando una porta è in modalità di compatibilità 802.1D, è anche in grado di gestire le BPDU di notifica delle modifiche alla topologia (TCN) e le BPDU con bit TC o TCA impostato.

Conclusioni

Il protocollo RSTP (IEEE 802.1w) include in modo nativo la maggior parte dei miglioramenti proprietari Cisco dello Spanning Tree 802.1D, come BackboneFast, UplinkFast e PortFast. Il protocollo RSTP può raggiungere una convergenza molto più velocemente se la rete è configurata correttamente, a volte solo in poche centinaia di millisecondi. I timer 802.1D classici, come il ritardo di inoltro e max_age, vengono utilizzati solo come backup e non dovrebbero essere necessari se i collegamenti point-to-point e le porte edge sono identificati e impostati correttamente dall'amministratore. Inoltre, i timer non sono necessari se non vi è alcuna interazione con i bridge preesistenti.

Informazioni correlate

• Configurazione di MST (802.1s) / RSTP (802.1w) sui Catalyst Switch con CatOS
• Descrizione e configurazione della funzionalità Cisco Uplink Fast
• Strumenti e risorse
• Documentazione e supporto tecnico – Cisco Systems