Newsgroup: it.fan.marco-ditri
Titolo: Parliamo di spanning tree

Supponiamo di avere una coppia di switch collegati tra loro, con STP
attivo.
Ora attacchiamo a ciscuno una porta di un terzo switch con bpdufilter
attivo.
Cosa succede? Brutte cose chiaramente, ma che impatto avranno sul resto
della rete? Come ci si tutela da un caso del genere? storm-control
broadcast è sufficiente?
Il terzo switch non è sotto il mio controllo, quindi si può assumere
una configurazione ostile a piacere.
-- 
ciao, | Those people who think they know everything
Marco | are a great annoyance to those of us who do. (Isaac Asimov)

 
Non sono un espertone, ma tipicamente prima di effettuare un operazione
del genere si fa un minimo di analisi.
Concordo che il terzo switch non sia di tua competenza ma in ambito
di reti aziendali o comunque di produzione va sicuramente verificato
il peso per poter determinare nel ricalcolo dello SPT chi e' "albero"
e chi "foglia".
Se la rete non e' poi cosi' complicata puoi decidere di disabilitare
lo SPT sul terzo switch.
Fra

rootguard puoi evitarlo).
Avevo già preso nota di configurarlo. :-)
-- 
ciao,
Marco

Concordo che il terzo switch non sia di tua competenza ma in ambito
Non ho scritto che non è di mia competenza, ma che proprio non ne ho il
controllo. Quindi devo prevedere la possibilità di una configurazione
ostile.
È uno scenario di service provider, non enterprise.



Temo che l'unica vera tutela in una situazione del genere sia quella di 
evitarla qualora possibile, altrimenti far sottoscrivere una lettera di 
assunzione di responsabilità al proprietario dello switch alieno dove si 
indicano espressamente le cose da non fare e si prospettano richieste di 
risarcimenti faraonici in caso di inadempienza.
Non c'è comando ios che ti tuteli completamente contro gli incompetenti, nel 
tuo caso specifico puoi limitare i danni facendo in modo che lo switch 
alieno lavori solo in vlan ben circoscritte, ovviamente mantenendo il 
protocollo pvst (per vlan spanning tree) di default, ma se queste vlan 
debbono essere condivise da altri non puoi evitare del tutto i potenziali 
danni a terzi.
Ciao,
         Tosh. 

danni a terzi.
Le VLAN sono dedicate ai clienti. Per essere più chiaro: se il cliente
sbaglia la configurazione e la *sua* rete si rompe è un problema suo, se
sbaglia la configurazione e mette in crisi i miei 6500 è un problema mio.
Le PVLAN potrebbero essere una soluzione, ma aggiungono complessità che
eviterei volentieri e quindi mi accontenterei di una soluzione di
compromesso che in caso di problemi causati dall'utente limita l'impatto
solo alla sua connettività.



Onestamente non vedo come le pvlan possano essere una soluzione in quanto mi 
risulta che nascano per isolare gli host tra di loro e non abbiano nessun 
effetto sul traffico di "servizio" come lo spanning tree.
Piuttosto con dei 6500 puoi fare altri giochini interessanti, tipo 
configurare le due porte in etherchannel e collegarle su due moduli diversi 
dello stesso switch, questo eliminerebbe alla radice il problema dello 
spanning tree in quanto diventerebbe un unico link logico, manterrebbe le 
proprietà di ridondanza e raddoppierebbe pure la banda, ma se vuoi il 
massimo del fault tolerance e devi quindi utilizzare due switch temo non sia 
una soluzione applicabile.
Ciao,
        Tosh. 

una soluzione applicabile.
Già. L'esercizio nasce dal requisito progettuale di avere due switch
separati, e se non li collego con un trunk non è possibile garantire il
servizio se uno dei link verso il cliente viene disconnesso (perché il
router a monte continuerebbe a mandare traffico in quella direzione).


Marco d'Itri ha scritto:

Allora alla fine come hai arginato il problema?
trunk,loop,PVLAN,e-mail?

trunk,loop,PVLAN,e-mail?
Non ci sono stati progressi significativi, visto che nel frattempo ho
dovuto seguire altre questioni.
Ho velocemente provato ad attivare rapid-pvst senza una configurazione
particolare e mettere gli switch in loop ma in questo modo si bloccano
link che non c'entrano niente con quello.
Trattandosi di porte FE non è possibile che la causa sia traffico
eccessivo (che comunque a posteriori non risultava nelle statistiche
del carico), quindi la mia ipotesi è che venga bloccata una intera porta
invece che solo la VLAN interessata. Devo trovare del tempo per RTFM su
rapid-pvst in modo da capire cosa succede esattamente.
Purtroppo sto già usando questi switch per altri servizi e non ho una
coppia di 6500 che mi avanzano, :-) quindi non posso fare troppe prove
empiriche.


broadcast è sufficiente?
Ho trovato una soluzione parziale: loopguard mi tutela esattamente da
questo problema, perché disattiva la porta se lo switch non ci riceve
più BPDU.
Ha il difetto che se lo switch del cliente non parla lo STP allora
diventa dannoso, perché in quel caso mancherebbe una sorgente locale di
BPDU e quindi appena uno dei due link si interrompe lo switch disattiva
anche l'altro. Ma per ora mi accontento...


 più BPDU.
Dovresti però fare in modo che lo switch del cliente diventi root per quella 
vlan, altrimenti non funziona.
Ciao,
         Tosh. 

vlan, altrimenti non funziona.
Non ti seguo. Uno switch che partecipa allo spanning tree genera BPDU
anche se non è il root switch.



Solo verso le porte downstream nella topologia ad albero, in upstream 
trasmettono solo in casi particolari, tipo elezioni o cambi ti topologia.
Le bpdu viaggiano dal root bridge a scendere, in effetti ciascun switch 
riceve le bpdu da quello upstream, le elabora e le ritrasmette su tutte le 
sue designated ports aggiungendo i relativi costi.
Se osservi bene il documento di cisco che parla del loopguard vedi che nel 
disegno indica quali porte dove attivarlo solo delle porte upstream, o root 
port.
Ciao,
        Tosh.