A proposito dell'autore

Trent'anni, sistemista Unix, specializzato su Solaris, sistema Operativo di casa Sun. Attualmente lavora come consulente presso una delle aziende sanitarie presenti sul territorio italiano. Certificato Sun SCSA (Solaris Certified System Administrator) e Sun SCNA (Solaris Certified Network Administrator), è responsabile dei sistemi cluster Sun SPARC Midrange, e della Storage Area Network FC presenti nei CED dell'azienda. Attualmente studia per conseguire la certificazione Sun Cluster 3.2 Administrator. In passato ha lavorato in ambito networking presso varie realtà prevalentemente su apparati Cisco e Nortel. Ha frequentato l'Academy CCNA e Fundamentals of Wireless, e cerca di mantenere vive le conoscenze acquisite in quest'ambito, nonostante la sua predilezione per l'ambito sistemistico Unix e la passione per Solaris siano la sua prima scelta.

Introduzione

STP (Spanning Tree Protocol) è definito nello standard 802.1d di IEEE.

Lavora, naturalmente, a layer2 per mantenere una topologia priva di loops fisici, al costo di una cattiva gestione dell’instradamento dei frames.

A meno che non parliamo di una LAN pesantemente congestionata, gli svantaggi dell’uso di STP sono impercettibili, mentre parlando dei vantaggi, la liberazione da loops infiniti evita grossi guai, guai che possono portare a rendere la rete completamente inutilizzabile a causa del flooding generato da broadcast storm, loops da traffico di tipo unknown forwardato all’infinito e multicast “impazziti”.

I path rindondanti, mentre assicurano affidabilità e fault recovery, causano non pochi problemi ai nostri amici switches. Tra quelli fondamentali Cisco ricorda i Broadcast Storm (dove Broadcast e Multicast, questi ultimi trattati allo stesso modo dei primi a layer 2, vengono messi in un circolo vizioso e deleterio e continuamente ritrasmessi), l’instabilità nell’organizzazione dell CAM table (i frames vengono ricevuti su più porte, quelle rindondanti, e i relativi source address “imparati” più volte causando problemi di indecisione allo switch) e inoltre, la trasmissione di frames uguali multipli, anche se questi ultimi, vengono scartati una volta arrivati ai layers più alti e più o meno tenuti a bada dai protocolli più intelligenti che vi risiedono.

Ricordiamo che, non esistono a layer2, metodi che controllino la durata della vita del frame, come invece succede, ad esempio a layer 3 nel routing col Time To Live (TTL), che “uccide” dopo tot passaggi il pacchetto decrementando di uno il valore di TTL a ogni passaggio su un Hop.

Detto questo, capiamo meglio quanto sia necessario avere un rimedio ai molteplici mali dello switch rindondante: STP è la cura.

STP non fa altro che mettere le porte degli switches in stato BLOCKING o FORWARDING. Cosa significano questi due stati, sembra ovvio e comprensibile dal nome.

Le porte in stato FORWARDING sono considerate appartenenti allo stesso Spanning Tree. Questo non è nient’altro che un path pulito, senza link rindondanti, con un’unica strada per giungere a qualsiasi destinazione. Le porte in BLOCKING, sono quelle che, secondo l’algoritmo, sono le più scomode rotte per giungere a una stessa destinazione.
I link resi inoperanti da STP restano in attesa; quando un path cade per qualche problema, entrano in azione per garantire la continuitù di servizio in modo tra sparente e rendere la rindondanza utile e intelligente.

Come abbiamo accennato all’inizio, STP rende la rete switchata priva di loops fisici. Questi sono dati solaitamente da tre tipi di traffico:

  • Broadcast
  • Unknown
  • Multicast

Esempio

Abbiamo 4 switches:

A manda un broadcast, B lo riceve e come da copione lo spedisce fuori dalla porta e0/2, arriva a D che fa lo stesso, e anche C. La palla torna ad A che vede un Broadcast e lo reinvia. questo frame girerà all’infinito assieme a tutti gli altri generati. Stessa cosa succederà per i Multicast e per il traffico di tipo sconosciuto. Risultato: la rete sarà inutilizzabile o molto congestionata nel giro di poco tempo.

Il nostro amico STP invece calcola tramite la cooperazione di tutti gli switches e decide che il link tra A e C si può sacrificare, in quanto, gli switches possono comunicare tra loro benissimo usando il path restante, eliminando il problema che abbiamo visto.

Immaginate la situazione di prima, e rendetevi conto che abbiamo fatto piazza pulita del traffico anomalo.

E se cade il link tra A e B? Niente paura, STP calcola e attiva il link A-C. L’utente finale non saprà nemmeno cos’è successo, o quasi.

Funzionamento

STP decide quali interfacce sono attive o meno. Traccia un percorso, calcolato su solide basi, come vedremo dopo. Se un’interfaccia non è nel percorso deciso, viene messa in BLOCKING state.

STP elegge un bridge principale detto root bridge, sul quale tutte le porte sono in stato FORWARDING. Tutti gli altri bridges, invece, si accontentato di una root port, selezionata tra quelle con un “costo” minore nel path verso il bridge root. La porta root si mette in FORWARDING. E l’albero prende forma.

Su ogni segmento della rete switchata, STP seleziona una “designated port” che risiede sempre sullo switch con costo minore nel path verso il root bridge, laddove tutto inizia. La designated port è in stato FORWARDING e inoltrerà il traffico su quel segmento.

Tutto il resto va in BLOCKING state. Giusto per non creare immagini mentali errate, una porta in questo stato non può inoltrare traffico, ma può ancora riceverlo.

Inoltre, bisogna fare molta attenzione: le informazioni che girano tra gli switches del nostro Tree sono ricevuti da tutti gli switches e porte in qualsiasi stato. E’ fondamentale che ognuno continui a ricevere costantemente informazioni fresche in modo da poter essere pronto e avere riferimenti attendibili quando ci sarà bisogno di cambiare lo Spanning Tree.

Quando un link cade il gioco delle assegnazioni ricomincia e lo stesso accade quando un nuovo switch entra in rete.

Logica di Spanning Tree

Ora, vediamo nel dettaglio, come avviene lo scambio di informazioni e come esse sono usate nella designazione delle cariche. Ogni switch invia dei frames chiamati BPDU (Bridge Protocol Data Units ) opportunamente formattati per contenere le informazioni di rito. All’inizio del processo ogni switch dice agli altri di essere il root bridge. I BPDU contengono diverse informazioni tra cui:

– BID (Bridge ID) = l’identificativo del dispositivo, composto dalla concatenazione del valore “priority”, di default 32768 con range da 0 a 65535 e di uno dei MAC address, valore anche quest’ultimo che può essere specificato a manina. Il valore di BID è tanto migliore quanto più basso.

– Costo = questo valore è per ora 0, in quanto indica la distanza del dispositivo dal root bridge. Essendo convinto di essere il root bridge imposta il costo a 0.

Il Root Bridge viene eletto se ha il BID più basso. L’elezione dipende in pratica dalla priorità assegnabile dall’amministratore. Solo in caso di eguale priorità viene fatto il check sul MAC “più basso” per decidere chi sarà eletto. Non appena uno switch riceve un Hello BPDU contenente un BID più basso, smette di proclamarsi root, finchè ne resterà solo uno. Il perdente non smette di inviare Hello, ma anzi continua, spammando per la LAN il BID del bridge vincitore.

Come già detto, il leader dello Spanning Tree mette tutte le porte in FORWARDING. Nel frattempo gli altri switches scelgono una porta root, quella che riceve BPDU al costo minore dal root bridge e le mette in FORWARDING. Designated switch e designated port vengono scelti nei segmenti a seconda di quale sta nel path con costo minore, sempre verso il root dello Spanning Tree.

Il costo è l’unità di misura fondamentale nella costruzione dell’albero. Può sempre essere settato dall’amministratore, in modo che possa influenzare a suo piacimento il processo di elezione, oppure può essere lasciato ai defaults stabiliti da IEEE (Cisco usa questi valori nei Catalyst), stabiliti negli anni ’80 e revisionati nei ’90 con l’avvento di Gigabit Ethernet. Infatti il tipo di media influenza il costo di default.

Il costo totale di un percorso è dato dalla somma del costo contenuto nel BPDU ricevuto da uno switch e da quello del path ricevente.
Reality Show

Ogni due secondi, di default, un Hello BPDU viene lanciato e il costo aggiunto dallo switch ricevente che lancia a sua volta il proprio Hello. Quando un bridge non riceve più Hello, pensa che qualcosa non stia andando per il verso giusto e inizia il processo di rielezione per ristabilire un path funzionante. Le opzioni che influiscono sulla velocità di reazione sono l’Hello Time, che è il tempo di attesa, 2 secondi per default, che un bridge fa passare tra un BPDU e l’altro e il MAx Age, di default 20 secondi e di solito multiplo dell’Hello time, che stabilisce quanto tempo uno switches deve stare in attesa senza ricevere Hello prima di reagire e cercare di cambiare lo Spanning Tree.

Quando un link cade, e uno switch si accorge che è successo, potrebbe reagire e forwardare traffico prima che la convergenza sia completa in tutta la rete. Questo può creare, seppur per breve tempo, dei doppi path e i soliti vecchi e temuti physical loops. Per evitare ciò lo switch mette le porte in due stati transizionali prima di passare da BLOCKING a FORWARDING. Questi stati sono LISTENING e LEARNING e la transizione è regolata dal parametro Forward Delay. Il primo stato mette il bridge in ascolto di BPDU contenenti soluzioni migliori mentre il secondo successivo impara la nuova locazione dei MAC address per scrivere la nuova CAM table. Per un totale di 50 secondi, lo switch attende 20 secondi per essere certo di aver smesso di ricevere Hello, 15 secondi li spende in LISTENING e altri 15 in LEARNING per imparare gli indirizzi fisici e la loro posizione rispetto al nuovo path. Dopo di che, la porta passa in FORWARDING. In stato di LISTENING, il root bridge invia un frame chiamato TCN, ovvero Topology Change Notification, dove dice agli altri membri dello spanning Tree di mettere in timeout i vecchi indirizzi MAC in memoria. La convergenza ci costa quindi 50 secondi. Tanti! Sono d’obbligo quindi rimedi estremi.

Etherchannel e Portfast

Da due a otto link corrono paralleli tra due switches, e vengono visti da STP come uno unico. Il vantaggio sta nel fatto che, se un link fallisce, STP continua a usare gli altri e non ricalcola lo spanning tree finchè almeno uno dei link è attivo. Altro vantaggio palese di Etherchannel è che tutti i link sono FORWARDING o BLOCKING e, di conseguenza la banda disponibile cresce quanto crescono i link legati in un unico “Canale”.
Implementando multipli link senza usare etherchannel darebbe il risultato che STP bloccherebbe tutti i link meno uno.

Portfast è utile quando il dispositivo connesso non è uno switch o un brdige appartenente allo Spanning Tree. Permette, in sostanza, di mettere una porta in Forwarding senza attendere lo scadere dei timers di STP.

E’ utile al Layer Access o ovunque ci siano end-user devices attaccati che non sono potenziali creatori di loops fisici.

Infine… lo standard IEEE 802.1w definisce RSTP, il fratellino veloce di STP, che risolve il problema di lentezza nella convergenza e introduce alcune innovazioni. Praticamente, un alleato più affidabile per le reti moderne. RSTP è implementato nelle immagini di IOS e CatOS che contengono la sigla EI. Sebbene il concetto rimane lo stesso alcuni accorgimenti rendono possibile una migliore gestione del protocollo, e migliori tempi di risposta e convergenza.

Post correlati

Close
Entra in contatto con altri professionisti ICT, seguici su Facebook e Twitter: