STP
Introduzione
Cos'e'
lo Spanning Tree Protocol
Poiche'
gli switch sono pensati per lavorare efficacemente su reti di
qualsiasi dimensione ci si puo' domandare se supportano
configurazioni ridondate tipiche delle reti piu' grandi. In
effetti e' possibile ed auspicabile che vengano utilizzate delle
topologie a grafo nella progettazione di reti dotate di switch.
Ma un grafo implica dei loop, improponibile in quanto
un ciclo puo' determinare una saturazione o blocco della rete per
la presenza dei pacchetti imprigionati al suo interno (cosa che
avverrebbe in particolare con i broadcast generati per popolare
la CAM).
Fortunatamente tutti gli switch Cisco sono dotati
di algoritmo STP (Spanning Tree Protocol) che estrae un albero dal grafo
di switch da noi progettato e implementato disattivando le porte
che generano cicli. STP dinamicamente gestira' le varie porte
sfruttando quelle inizialmente disattivate in caso di failure di
switch o di porte attive.
La trattazione che segue e' basata sul
funzionamento degli switch Cisco 'set' based. Si tenga presente
che i valori e i range di priorita', la struttura del portID ed
altri valori possono variare in funzione del modello di switch e
della versione di sistema operativo presente.
Algoritmo
di STP
Sia assegnato il grafo costituito di switch ai suoi nodi. L'algoritmo STP costruisce il suo albero gestendo due problematiche:
determinazione della root dell'albero, che si chiama 'root bridge'
determinazione del percorso migliore verso il 'root bridge'
Le
informazioni tra gli switch vengono scambiate con broadcast
tramite dei pacchetti di livello 2 che si chiamano BPDU (Bridge
Protocol Data Unit). Per il momento accontentiamoci di sapere che
ogni BPDU contiene un valore di BridgeID. Quest'ultimo e' un
numero di 10 byte consistente in un valore di priorita', nei 16
bits piu' significativi, e un MAC address dello switch nei
restanti 8 byte. La funzione del BridgeID e' quella di dare una
priorita' ad uno switch, che come si vede ha un valore in parte
casuale (MAC) e in parte configurabile (i 16 bits di default
hanno il valore 32768).
Determinazione
della root dell'albero
Nel momento iniziale ogni switch dichiara di essere il 'root bridge' ed invia BPDU a tutti i suoi vicini. Questi ultimi confrontano il BridgeID ricevuto con quello loro. Poiche' nello STP la regola e' che “cio' che ha valore piu' basso vince” se il BridgeID ricevuto ha un valore piu' basso il ricevente rinuncia al titolo di 'root bridge' e propaga il BridgeID ricevuto ai suoi vicini.
Poiche' i MAC address sono unici alla fine uno ed un solo switch non avra' rinunciato al titolo di 'root bridge'. Il campo priorita' e' impostato per default a 32768. Essendo posizionato nei 16 bits piu' significativi del BridgeID se modificato sara' determinante nell'elezione del root bridge. In effetti e' proprio questo il motivo della sua esistenza: consentire al progettista di poter intervenire nella scelta del root bridge con un parametro settabile. Questo perche' lo switch root dell'albero sara' probabilmente uno switch abbastanza trafficato: e' bene che sia in posizione baricentrica nella rete e sufficientemente performante, non e' opportuno che sia uno switch nella rete di accesso. Senza configurazione di priorita' la scelta del root dipende dal MAC e quindi e' totalmente casuale.
Determinazione
del percorso migliore verso il root bridge
Consideriamo
lo switch S1 nella nostra rete con STP. S1 non e' root bridge.
Supponiamo che S1 riceva BPDU provenienti dal root bridge dalle
porte P1 e P2. Si puo' concludere che e' stato determinato un
loop e che va eliminato. Per fare questo una delle due porte
va bloccata e posta in quello che si chiama 'blocking state'.
L'altra fara' passare il traffico e verra' posta in quello che si
chiama 'forwarding state'. Una porta disabilitata dal progettista
volontariamente si mette in 'disabled state'. In una rete stabile ogni porta e'
in uno di questi tre stati ma il passaggio da blocking a
forwarding non e' immediato ma avviene attraverso gli stati
'listening' e 'learning'. Cosi' complessivamente una porta puo'
stare in ogni istante in uno di 5 stati in una rete con STP. Nello
stato di listening la porta non fa altro che analizzare le BPDU
per scegliere la nuova root port. Nello stato di learning la
porta impara i MAC address della rete senza fare forwarding di
pacchetti.
Resta da chiarire tra le porte P1 e P2 quale vada bloccata e quale no. Basare la scelta sul caso non e' un'alternativa valida in quando la giusta idea e' quella di scegliere la porta associata al percorso piu' valido verso il root bridge. Parametri validi sono la priorita' degli switch lungo questo percorso e la capacita' dei link (per es. se P1 ha un percorso con Fast Ethernet e P2 un percorso con GigaEthernet e' meglio scegliere P2).
L'algoritmo di scelta per le nostre due porte P1 e P2 si basa sul valore di BridgeID gia' introdotto, su un valore di costo che e' settabile per porta e su un valore di PortID che e' anch'esso settabile per porta.
Per default ad ogni porta e' associato un costo che e' inversamente proporzionale alla banda a disposizione sulla stessa. Questo valore non e' lo stesso per tutti gli switch e per tutte le versioni di SO. Al di la del valore specifico l'idea e' che, ad esempio, una porta GigaEthernet avra' priorita' inferiore rispetto una porta Ethernet in quanto la prima e' preferibile (ricordiamo che il valore piu' basso vince). Tale parametro e' modificabile dall'operatore per porta.
Per default ad ogni porta viene associato un PortID. Questo e' un valore a 16 bit di cui 6 sono riservati alla priorita' della porta (variabile da 0 a 63 con 32 di default). I restanti 10 bit sono derivati dal numero logico della porta sullo switch. Tale parametro e' modificabile dall'operatore per porta.
Avendo introdotto tutti i concetti necessari ecco l'algoritmo di scelta che permette di comprendere cosa viene scelto tra le porte P1 e P2 e cosa viene scelto in tutti gli altri casi dove piu' porte hanno path validi per raggiungere il root bridge:
si presume che il Root BridgeID sia uguale per entrambe le porte in quanto la root della rete e' unica
la porta che ha il 'path cost' verso il root bridge piu' in basso vince
la porta che ha il vicino con BridgeID piu' basso vince
la porta con PortID piu' basso vince
Una BPDU, oltre che al valore di BridgeID dello switch mittente, contiene anche il BridgeID dello switch che lo sta ritrasmettendo nonche' il valore di path cost verso il root switch e il PortID della porta che sta ritrasmettendo la BPDU. Infine la BPDU contiene anche i timers associati allo STP di cui al prossimo paragrafo. Se la porta P1 ha un path cost piu' basso della P2 quest'ultima andra' in blocking. Se i path cost di P1 e P2 sono uguali vincera' il BridgeID piu' basso tra i vicini collegati alle porte P1 e P2. Se anche questi sono uguali vince il PortID piu' basso. Sostanzialmente, solo nella peggiore delle ipotesi la scelta sara' casuale e cioe' determinato dal numero della porta nello switch.
Nel caso in cui piu' switch si trovano nello stesso segmento di rete, ad esempio nel caso di piu' switch collegati ad un hub, la scelta piu' saggia e' eleggere un rappresentante, chiamato 'designed switch' che si occupi di inviare i dati verso il root bridge. Vince chi ha il costo piu' basso verso il root Bridge.
Ricostruzione
dello Spanning Tree
Non appena raggiunta la stabilita' il traffico passera' sui path dell'albero determinato dallo spanning tree. Resta da chiarire cosa succede se un guasto determina il blocco del traffico su un link. Poiche' le BPDU inviate dal root bridge non arriveranno piu' a tutti gli switch dell'albero quelli interessati si accorgeranno della failure. Poiche' le porte in stato di Blocking comunque ricevono le BPDU dal root sara' possibile capire se si tratta di una indisponibilita' dell'intero root bridge o se vi e' solo un problema in un link. Se uno switch, che per comodita' indichero' con S1, non riceve piu' le BPDU del root da nessuna porta allora dichiarera' di essere il nuovo root switch e partira' un ricalcolo dell'albero. Se invece riceve la BPDU dal root da una porta messa in blocking allora la porta cambiera' il suo stato fino a giungere in forwarding.
Tutto quanto indicato segue precise temporizzazioni:
Le BPDU vengono inviate per default ogni 2 secondi. Questo tempo si chiama 'hello time' ed e' modificabile dall'operatore tra 1 e 10 secondi
Se non si ricevono BPDU per un tempo massimo pari per default a 20 secondi si considera perso lo switch mittente. Questo tempo si chiama 'max age' ed e' modificabile dall'operatore tra 6 e 40 secondi
Se una porta deve passare da blocking a fowarding permane per default per 15 secondi negli stati intermedi di listing e learning. Questo tempo si chiama 'forwarding time' ed e' modificabile dall'operatore tra 4 e 30 secondi
Facendo qualche calcolo si vede che il tempo medio di recovery da un guasto varia tra i 30 e i 50 secondi. Questo si chiama 'tempo di convergenza' ed e' un valore di primaria importanza in quanto indica un tempo in cui la rete in parte non funziona correttamente. Modificando i settaggi e' teoricamente possibile ottenere dei tempi di recovery da fault molto piu' bassi ma l'operazione manuale in questo caso e' da sconsigliare in quanto dipendente da fattori legati alla struttura della rete. Piuttosto vanno seguite le strategie alternative indicate nel paragrafo successivo.
Ridurre
il tempo di convergenza
E' molto piu' comodo e sicuro lasciare al Catalyst il settaggio opportuno indicando esclusivamente il diametro della rete. Tale parametro, per default a 7 che e' il valore massimo, indica il numero di switch che un pacchetto deve attraversare per raggiungere una destinazione nel caso peggiore. Poiche' per default e' pari al valore massimo va corretto senza esitazioni per ottenere tempistiche migliori.
Oltre a questo e' possibile selezionare tre modalita' differenti per migliorare i tempi di convergenza dipendenti dalla topologia e quindi tutte disabilitate per default. Queste sono: port-fast, uplink-fast, backbone-fast.
PORT-FAST va utilizzato esclusivamente su porte con collegati server e workstation. Non va usato su porte con altri hub o switch collegati. Consente una transizione immediata da 'block state' a 'forwarding state' senza passare per gli stati intermedi. Questi ultimi giovano per prevenire loops che non possono tuttavia verificarsi in porte collegate a PC;
UPLINK-FAST consente di unificare tutte le root-ports lasciandone una sola attiva. In caso di fail un'altra porta si attivera' e cosi' a seguire. In ogni istante solo una porta e' in forwarding state. Cio' consente di evitare loop pertanto si puo' accelerare il tempo di convergenza con lo stesso criterio del PORT-FAST; in una rete si puo' utilizzare per collegare gli switch dell'access-layer al distribution-layer. Non va usato nel core layer; questo switch non deve diventare root e di default la sua priorita' va a 49152 e il portcost aumenta di 3000; lavora VLAN based;
BACKBONE-FAST consente di accelerare il tempo di convergenza quando un Designed Switch perde il contatto col root switch; andrebbe sempre utilizzato in una rete;
Esempio
Un router Cisco, anche di fascia bassa,
e' in grado di effettuare bridging tra le sue porte e
comportarsi esattamente come uno switch. Un esempio tipico di
applicazione si ha nel caso di utilizzo di protocolli che non
possono essere gestiti da routers quali Netbios. Ecco un esempio
(qui siamo in un Cisco 827):
bridge-group 1 protocol ieee
interface Ethernet0
ip address 192.168.30.1 255.255.255.0
bridge-group 1
!
interface ATM0
ip address 151.99.200.10 255.255.255.0
no atm ilmi-keepalive
bundle-enable
dsl operating-mode auto
bridge-group 1
!
Router#show bridge group
Bridge Group 1 is running the IEEE compatible Spanning Tree
protocol
Port 3 (ATM0 RFC 1483) of bridge group 1 is forwarding
Port 2 (Ethernet0) of bridge group 1 is forwarding
Router#show spanning brief
Bridge group 1
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0004.27fd.41d4
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 0004.27fd.41d4
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Designated
Name
Port ID Prio
Cost Sts Cost
Bridge ID Port ID
-------------------- ---------- ----
------- ---
----- -------------
-------
Ethernet0
128.2
128 100 FWD
0 32768 0004.27fd.41d4
128.2
ATM0
128.3
128 1562 FWD
0 32768 0004.27fd.41d4
128.3
Comandi
utili
set
spantree root [vlan] [dia diameter]
Nota: la priorita' viene settata a 8192
set spantree secondary [vlan]
[dia diameter] Nota: la priorita' viene settata a
16242
set spantree priority priority [vlan]
set spantree hello time [vlan]
Nota: default 2, range 1-10
set
spantree fwddelay time [vlan]
Nota: default 15, range 4-30
set spantree maxage time
[vlan] Nota: default 20,
range 6-40
set spantree backbonefast [enable|disable]
set
spantree uplinkfast [enable|disable]
set spantree portfast m/n
[enable|disable]
set spantree portvlanpri m/n
priority vlans Nota
Settabile solo nelle porte trunk (range 0-63)
set
spantree portpri m/n
priority
Nota: default a 32 range 0-63
set
spantree portvlancost m/n
priority vlans Nota:
Settabile solo nelle porte trunk
set
spantree portcost m/n
cost
show spantree
Switch con IOS. Catalyst 3750G con c3750-ipbase-mz.122-50.SE5.bin
Di default e' attivo lo spanning-tree per VLAN. Ovvero ogni VLAN ha una sua istanza di spanning-tree. Questa configurazione di default e' indicata dalla presenza del comando:
spanning-tree mode pvs
Come si vede il root e' uno switch che si trova collegato alla porta 2/0/3
core3750_01_02#show spanning-tree active
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000b.fd03.8040
Cost 4
Port 57 (GigabitEthernet2/0/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
core3750_01_02#show spanning-tree root
Root Hello Max Fwd
Vlan Root ID Cost Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- ------------
VLAN0001 32769 000b.fd03.8040 4 2 20 15 Gi2/0/3
VLAN0002 32770 d4a0.2a23.e480 0 2 20 15
VLAN0003 32771 d4a0.2a23.e480 0 2 20 15
VLAN0004 32772 d4a0.2a23.e480 0 2 20 15
VLAN0005 32773 d4a0.2a23.e480 0 2 20 15
VLAN0006 32774 d4a0.2a23.e480 0 2 20 15
VLAN0007 32775 d4a0.2a23.e480 0 2 20 15
VLAN0008 32776 d4a0.2a23.e480 0 2 20 15
VLAN0009 32777 d4a0.2a23.e480 0 2 20 15
VLAN0010 32778 d4a0.2a23.e480 0 2 20 15
Il nostro switch e' un
centro stella ma, di default, non si e' settato come root,
infatti c'e' una root port.
Allora forziamolo a root per tutte le vlan che abbiamo:
spanning-tree vlan 1-10 root primary (che il router converte nel comando: spanning-tree vlan 1-10 priority 24576)
adesso:
core3750_01_02#show spanning-tree root
Root Hello Max Fwd
Vlan Root ID Cost Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- ------------
VLAN0001 24577 d4a0.2a23.e480 0 2 20 15
VLAN0002 24578 d4a0.2a23.e480 0 2 20 15
VLAN0003 24579 d4a0.2a23.e480 0 2 20 15
VLAN0004 24580 d4a0.2a23.e480 0 2 20 15
VLAN0005 24581 d4a0.2a23.e480 0 2 20 15
VLAN0006 24582 d4a0.2a23.e480 0 2 20 15
VLAN0007 24583 d4a0.2a23.e480 0 2 20 15
VLAN0008 24584 d4a0.2a23.e480 0 2 20 15
VLAN0009 24585 d4a0.2a23.e480 0 2 20 15
VLAN0010 24586 d4a0.2a23.e480 0 2 20 15
core3750_01_02#show spanning-tree
VLAN0001 (per comodita' riportiamo solo la VLAN1 ma per le altre c'e' la stessa indicazione)
Spanning tree enabled protocol ieee
Root ID Priority 24577
Address d4a0.2a23.e480
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Abbiamo due switch collegati tra loro con due porte in parallelo. Tutto funziona regolarmente. Ecco lo stato delle porte (questo e' lo switch root):
core3750_01_02#show spanning-tree interface gigabitEthernet 2/0/4 Vlan Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- VLAN0001 Desg FWD 4 128.58 P2p
core3750_01_02#show spanning-tree interface gigabitEthernet 1/0/4 Vlan Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- VLAN0001 Desg FWD 4 128.4 P2p
Come si vede nello switch remoto (che non e' root) una delle due porte e' messa giustamente in blocked
3750g_terzo# show spanning-tree interface gigabitEthernet 1/0/1 Vlan Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- VLAN0001 Root FWD 4 128.1 P2p
3750g_terzo# show spanning-tree interface gigabitEthernet 1/0/2 Vlan Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- VLAN0001 Altn BLK 4 128.2 P2p
Il backup funziona regolarmente e non e' stata necessaria nessuna configurazione speciale. Abbiamo solo forzato uno switch come root, perche' centro stella di una rete piu' complessa.
Nello switch remoto stacchiamo e riattacchiamo una delle due dorsali:
va giu': 2d23h: Disabling spanning tree port: GigabitEthernet1/0/2 (2F04610) 2d23h: Deleting spanning tree port: Gi1/0/2 (2F04610) 2d23h: STP PVST: deleted vlan 1 intf 237E038 ora torna su: 2d23h: set portid: VLAN0001 Gi1/0/2: new port id 8002 2d23h: Created spanning tree port Gi1/0/2 (1981700) for tree VLAN0001 (23246B0) 2d23h: Enabling spanning tree port: GigabitEthernet1/0/2 (1981700) 2d23h: STP: VLAN0001 Gi1/0/2 -> listening 2d23h: STP: VLAN0001 Gi1/0/2 -> blocking
Come si vede lo switch di root (quelle che si vedono sono interfacce collegate a coppia ad uno stesso switch) non blocca nulla. Sono gli altri switch a farlo:
Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Gi1/0/2 Desg FWD 4 128.2 P2p Gi1/0/3 Desg FWD 4 128.3 P2p Gi1/0/4 Desg FWD 4 128.4 P2p Gi2/0/2 Desg FWD 4 128.56 P2p Gi2/0/3 Desg FWD 4 128.57 P2p Gi2/0/4 Desg FWD 4 128.58 P2p
Questo perche vale la regola XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Altre
funzionalita'
Sfruttando
il meccanismo di priorita' per vlan consentito sui trunk e'
possibile creare piu' link paralleli funzionanti tra switch con
un carico distribuito in funzione della vlan di appartenenza.
Per una descrizione dettagliata di tali procedure e' possibile consultare il sito della Cisco.
Altre letture
Consiglio di consultare l’enorme documentazione disponibile on-line nel sito della cisco http://www.cisco.com/. E’ possibile trovare sempre tutto cio’ che si cerca.
Copyright 2002-2004 Gianrico Fichera – ITESYS srl –
Il
materiale di questa pagina non e’ sponsorizzato o
sottoscritto da Cisco Systems, Inc. Ciscoâ
e’ un trademark di Cisco Systems, Inc. negli Stati Uniti e
in altri stati. L’autore di questa pagina non si assume
nessuna responsabilita’ e non da nessuna garanzia
riguardante l’accuratezza e la completezza delle
informazioni presenti nonche’ da conseguenze sull’uso
delle informazioni presenti in questa pagina.
Il
sito web ufficiale della Cisco e’ http://www.cisco.com.
Nel caso si volesse utilizzare il contenuto di questa pagina
nella forma in cui e’ presentato rivolgersi all’autore
scrivendo a gianrico.fichera itesys.it.
E' possibile utilizzare il contenuto di questa pagina per fini
didattici (non lucro) purche' si dia credito all'autore.
This material is not sponsored by, endorsed by, or affiliated with Cisco Systems, Inc., Cisco, Cisco Systems, and the Cisco Systems logo are trademarks or registered trade marks of Cisco Systems, Inc. or its affiliates. All other trademarks are trademarks of their respective owners.