Newsgroup: it.comp.reti.cisco
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

Ciao,
Marco d'Itri wrote:


Prima bisogna capire come è stato configurato bpdufilter , per port o in
global config ?,
se fosse in global , allora la porta appena sente il primo BPDU avvia il
STP e aggiunge la porta al process STP perdendo in questo modo la funzione
di portfast,
se invece e per port , allora niente da fare, il loop è d'aspettare.
Comunque se lo switch è in possesso del cliente in sede distanti di
kilometri (Metro ethernet) , io personalmente farei una private vlan per
quel cliente con lo scopo di isolarlo dal mio process stp (layer 2).
Comunque il rischio grosso non è il loop in se stezo ma il root (con
rootguard puoi evitarlo).
ciao.
-------------------------------------------------------
Messaggio inviato da 
http://www.sandlab.org/newsgroup/
Accesso gratuito via web ai Newsgroup

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.


 Marco
-------------------------------------------------------



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).


 per forza non potrà crearsi un loop.
Pvlan e nato dalla esigenza dei   ISP per  poter scalare le vlans
assegnate hai loro clienti e le conseguenti subnet  IP,  Pvlan è una
tecnologia per poter isolare lan dal resto del network del ISP , ma la
parola ISOLARE non voi dire senza parlare con nessuno, queste vlan possono
comunicare con il mondo esterno via la primary vlan o con una promiscuos
vlan.
Vi faccio un es: Una azienda assicuratrice di Automobili chiede un
servizio di localizzazioni satellitare delle loro auto , il servizio si
trova presso il ISP (nel Back end ), il ISP li offre una   P2P per
l’acceso diretto hai servers di servizio, ma alla loro volta offre
l’accesso Internet , i suddetti servers sono alla loro volta connessi al 
sistema di back-up.
Si crea una pvlan per il cliente il quale contiene delle community vlans
per i servers e delle vlan host per il cliente , in piu si crea una
promiscuos per il sistema di backup e una a layer  3 sulla primary vlan
per fare routing verso Internet.
Ovviamente e soltanto un es. , senza specifiche ma la idea e quella.
Vi chiedo di studiare la tecnologia per poter capire i suoi pregi e 
logicamente anche i suoi difetti , la perfezione non è di questo mondo !.
Ciao a tutte due.



Sarò cocciuto e irrispettoso, ma continuo proprio a non vedere come si possa 
applicare una tecnologia del genere per risolvere il problema dei loop.
Come fai con le pvlan ad evitare che gli switch popolino in maniera 
sbagliata le proprie cam tables, che è poi il problema che risolve lo 
spanning tree?
Blocchi i broadcast sugli uplink?
Oppure filtri a livello di mac address?
Se blocchi i broadcast temo che ci sia qualche protocollo (arp?) che faccia 
fatica a funzionare.
Filtrare a livello di mac address, oltre ad essere una tecnica da suicidio, 
eviterebbe si i loop, ma con le cam popolate in modo errato il traffico non 
arriverebbe mai a destinazione.
Francamente mi sembra che sia come arginare la rottura della diga con un 
dito, ma forse mi sfugge qualcosa.
Ciao,
        Tosh.

Ciao Tosh,
lo scopo è limitare i danni dal assegnare al cliente una vlan con link
ridondati e ovviamente STP enable , in pratica Marco chiede un modo sicuro
di poter installare uno switch presso il cliente anche se lo manomettono
il protocollo STP dovrete in qualche modo  limite i danni  al suo Core.
Private Vlan fa un isolamento a layer 2 , e non partecipa in VTP , per
cio’ la config delle vlan dal cliente lo devi fare a mano , via telnet o
con un script .
Le risposte alle tue domande li trovi qui :
Una piccola introduzione la trivi qui:
http://www.cisco.com/warp/public/473/90.shtml
Qui il modo di configurare su 6500 :
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008007e717.html
Qui un esempio pratico :
http://www.brainbuzz.com/articles/get-article.asp?aid=12
ciao
Tosh wrote:


-------------------------------------------------------


 il protocollo STP dovrete in qualche modo  limite i danni  al suo Core.
Erny, lo scenario che stai descrivendo è molto particolare, sicuramente ben 
diverso dalle applicazioni convenzionali per le private vlan, questo non 
vuol dire che debba necessariamente essere una bufala, converrai però con me 
che si tratta comunque una soluzione alquanto macchiavellica.
Ma il vero punto è che se mai questa soluzione dovesse funzionare temo che 
sia necessario configurare le private vlan su tutti gli switch, compresi 
quelli del cliente.
A questo punto, dovendoti comunque fidare del cliente, tanto vale sperare 
che non attivi bpduguard, quantomeno riduci le possibilità di errori.
Ciao,
         Tosh. 

 che non attivi bpduguard, quantomeno riduci le possibilità di errori.
Non vedo il problema , mica puo fare loops o far influenzare il root con
alcun priority baso o altro visto che lui sara soltanto limitato a la sua
vlan (broadcast domin) e per poter uscire deve passare a layer 3 da un
router o firewall. 
Ciao Tosh



Erny,
l'argomento č piuttosto complesso e facciamo fatica a capirci in questo 
modo, in piů stiamo dando l'impressione di litigare quando invece entrambi 
vogliamo solamente cercare di imparare qualcosa di nuovo.
Ti mando una mail in pvt con il mio numero cosě ci scambiamo le impressioni 
a voce, dopo di che aggiorneremo gli amici del ng che fossero interessati.
Ciao,
        Tosh. 

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.