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:

   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:

    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:

   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.

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

Router# show spanning

 Bridge group 1 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 0004.27fd.41d4
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag not set, detected flag not set
  Number of topology changes 1 last change occurred 00:00:49 ago
          from Ethernet0
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15 
  Timers: hello 0, topology change 0, notification 0, aging 300

 Port 2 (Ethernet0) of Bridge group 1 is forwarding
   Port path cost 100, Port priority 128, Port Identifier 128.2.
   Designated root has priority 32768, address 0004.27fd.41d4
   Designated bridge has priority 32768, address 0004.27fd.41d4
   Designated port id is 128.2, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 41, received 0

 Port 3 (ATM0) of Bridge group 1 is forwarding
   Port path cost 1562, Port priority 128, Port Identifier 128.3.
   Designated root has priority 32768, address 0004.27fd.41d4
   Designated bridge has priority 32768, address 0004.27fd.41d4
   Designated port id is 128.3, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 41, received 0

 


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


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.


All untagged traffic received on an IEEE 802.1Q trunk port is forwarded with the native VLAN configured for the port.

If a packet has a VLAN ID that is the same as the sending-port native VLAN ID, the packet is sent without a tag; otherwise, the switch sends the packet with a tag.

To reduce the risk of spanning-tree loops or storms, you can disable VLAN 1 on any individual VLAN trunk port by removing VLAN 1 from the allowed list. When you remove VLAN 1 from a trunk port, the interface continues to send and receive management traffic, for example, Cisco Discovery Protocol (CDP), Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP), Dynamic Trunking Protocol (DTP), and VLAN Trunking Protocol (VTP) in VLAN 1.

CDP, PaGP, VTP messages are not modified, not tagged and do NOT travel over the native VLAN; these management frames travel theoretically untagged over VLAN1, even if VLAN 1 is restricted (VLAN minimization) or VLAN1 gets tagged by command "vlan dot1q tag native", or native VLAN is changed from default VLAN1. Howver, in reality, these messages just travel over the needed links without any VLAN specification in the header.

VLAN 1 is the default VLAN on all trunk ports in all Cisco switches, and it has previously been a requirement that VLAN 1 always be enabled on every trunk link. You can use the VLAN 1 minimization feature to disable VLAN 1 on any individual VLAN trunk link so that no user traffic (including spanning-tree advertisements) is sent or received on VLAN 1.

To reduce the risk of spanning-tree loops or storms, you can disable VLAN 1 on any individualized VLAN trunk port by removing VLAN 1 from the allowed list. This is known as VLAN 1 minimization. VLAN 1 minimization disables VLAN 1 (the default VLAN on all Cisco switch trunk ports), on an individual VLAN trunk link. As a result no user traffic, including spanning-tree advertisements, are sent or received on VLAN 1. 

When you remove VLAN 1 from a trunk port, the interface continues to send and receive management traffic, for example, Cisco Discovery Protocol (CSP), Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP), Dynamic Trunking Protocol (DTP), and VLAN Trunking Protocol (VTP) in VLAN 1.


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.