Newsgroup: it.comp.reti.cisco
Titolo: spanning-tree portfast...si o no?

Ciao a tutti.
Vorrei capire quali sono i vantaggi e gli svantaggi effettivi nell'uso dello 
spanning-tree portfast sulle porte. A quanto ho capito la sua abilitazione è 
potenzialmente pericolosa perché l'apparato non farà tutti i necessari 
controlli prima di uppare la porta e quindi un loop potrebbe buttarmi giù 
tutto. Se lo disattivo invece, perderò 20/30 secondi di tempo prima di avere 
la porta su, ma ci posso attaccare sopra di tutto.
Ora, da chi ha esperienza vissuta sul campo, vorrei capire se si trae 
effettivo beneficio da questo portfast, perché così come me lo sono 
immaginato ha più vantaggi che svantaggi.
Oppure il portfast ha la sua vera utilità se ci sono dei problemi di 
comunicazione tra host e switch perché evita che la porta debba perdere 
tempo a rinegoziarsi mantenendo il link su? In questo caso sarebbe 
assolutamente necessario impostarlo, soprattutto su link critici.
Grazie a chiunque voglia illuminarmi!
Bye
giaconet 

 assolutamente necessario impostarlo, soprattutto su link critici.
Ha senso impostarlo sulle porte che collegheranno solo host, insieme a
un sempre sano
spanning-tree bpduguard enable
che avrà l'effetto di mettere la porta in err-disable se qualcuno ci
attacca uno switch o un qualsiai altro apparato che parli (o propaghi) STP.
(o uno "spanning-tree portfast bpduguard default" in configurazione
globale che tagli ala testa al toro)
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 la porta su, ma ci posso attaccare sopra di tutto.
Da quel che ho capito io (c'è stata una lunga discussione
inerente ARP proprio tra me e Skull) e per come ti ha
risposto skull, lo svantaggio del portfast (ovvero rendere
alcune porte soggette a loop vanificando l'STP) lo puoi
annullare mettendo in bpduguard le porte soggette a portfast.
così facendo, la porta sotto portfast bypassa lo spanningtree
ed inizia subito a trasmettere, ma se per sfiga si dovesse
verificare un loop, dal momento che tale porta ha anche la
bpduguard, la prima volta che transita una bpdu li dentro
(ovvero si genera un loop), il bpduguard ti abbatte la
porta proteggendo il resto della rete.
Mi pare quindi di capire che in caso di uno switch standard
da 24 porte + uplink, dove le 24 porte sono i server e l'uplink
porta al centrostella, convenga mettere le 24 porte in portfast
con bpduguard e lasciare libere solo gli uplink per avere l'STP
attivo ma senza il suo ritardo trasmissivo nelle porte connesse
agli host.


Il che a dirla tutta non fa poi tanto male.
Se mi calcoli un topology change ogni qualche minuto ad occhio l'impatto è 
di gran lunga inferiore a quello di una macchina windows che lavora su 
risorse condivise e che quindi manda quantità industriali di broadcast; alla 
fin fine il flooding è solo per il primo frame, in una rete di 1000 computer 
puoi generare al massimo 1megabit e mezzo di flooding ogni ricalcolo 
considerando tutte frame di dimensioni massime e che tutti i computer stiano 
lavorando.
Il problema si sente un pelo di più al mattino quando tutti accendono i pc 
nell'arco di pochi minuti, ma nella mia esperienza non ho mai visto reti 
"sdraiate" per colpa di questa cosa.
Con questo non voglio dire che non si debba usare il porfast, la stessa 
cisco lo raccomanda come buona pratica, dico solo che l'assenza del portfast 
non mi ha mai creato problemi, mentre il portfast da solo può portare a loop 
e il bpduguard a chiamate di clienti che non riescono a collegare lo switch 
nella sala riunioni dove hanno bisogno di aggiungere porte urgentemente per 
una demo importante.
Senza contare che se attacchi uno switch che non gestisce lo spanning tree 
il bpduguard non può intervenire e ti tieni il rischio dei loop.
E' una questione di scelte e del male minore, che non sempre e in tutte le 
situazione è lo stesso.
Ciao,
         Tosh.


ti è mai capitato che una macchina windows ci metta un po' a tirare su 
la rete, non riesca a prendersi le polocy di dominio o perda un sacco di 
tempo all'avvio o non riesca a prendere un ip dal dhcp?
ecco, questo con portfast non succede perchè la porta parte subito in 
forwarding.
ovviamente questo è potenzialmente pericoloso. MOLTO pericoloso se ci 
attacchi uno switch - specialmente uno di quegli switch bastardissimi 4 
porte da 5 euro...
il bpduguard è d'obbligo un questi casi (secondo me, eh!)
però ogni tanto qualche pippa strana succede, ma alla fine il gioco vale 
la candela...

Gandalf Corvotempesta ha scritto:

ma infatti il problema ti capita (e mi è capitato) con uno switch da 5 euro.
nonostante per politiche non forniamo apposta hub e switch la gente ha 
sempre la bella idea di portarlo da casa perché così ci attacca pure il 
portatile personale alla rete...

 portatile personale alla rete...
Che fastidio da uno switch da 5 euro rispetto ad uno da 500?
Se il problema è quello esposto da Tosh, ovvero il BPDUGuard non
funziona se lo switch che attacchi non supporta STP, mi pare strano.
Le BPDU degli switch STP compatibili vanno in circolo, emesse dagli
switch stp, se una BPDU torna all'origine, come nel caso di uno
switch da 5 euro connesso in loop ad uno switch STP, si è formato 
un loop.
Se il tuo switch non supporta STP, non emetterà BPDU per conto suo, ma
lascerà girare ugualmente quelle degli altri. Anche in questo caso se
una BPDU torna indietro hai un loop e lo switch compatibile con STP,
ovvero quello con il portfast+bpduguard ammazza la porta.
In sostanza, a livello STP, uno switch da 5 euro è inesistente,
sarebbe come mettere in collegamento due porte sullo stesso switch
tramite una patch, ed in tal caso STP ti protegge disattivando,
in teoria, la porta con mac più alto.

 la candela..
Purtroppo anche con il bpduguard non ti togli il rischio di loop... 
specie con gli switch l2 NA. io il portfast lo lascio su tutti i nodi di 
distribuzione e lo tolgo dai nodi di uplink.
TheArchitect

 distribuzione e lo tolgo dai nodi di uplink.
NA cosa sarebbe?
Comunque sia, se lo lasci nelle porte 'host' il primo che ti collega
uno switch in loop ti ammazza la rete indipendentemente dal bpduguard?
A me fa strano, Cisco stessa consiglia di attivare portfast+bpduguard
sulle porte connesse agli host, per evitare loop.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

funziona se lo switch che attacchi non supporta STP, mi >pare strano.
Prova a collegare uno switch da 5 ? ad un catalyst da 100.000, poi metti in 
loop due porte dello switch da 5? e vedi come balla il tuo catalyst da 
100.000, bpduguard o no.
Quello che volevo dire è che ne portfast ne bpduguard non sono la panacea 
contro tutti i mali, io seguo diverse reti piuttosto grandi con poche o 
nessuna porta in portfast da anni e non ho mai avuto lamentele di 
malfunzionamenti, problemi al boot o cali di prestazioni.
I pc impiegano spesso molto di più a fare il boot della relativa porta ad 
andare in forwarding, senza contare il fatto che le schede di rete moderne 
molto spesso rimangono sempre alimentate per consentire il wake on lan, non 
sono certo che questo escluda il meccanismo del flush, ma ci sono buone 
possibilità.
Il problema del flooding lo ritengo decisamente trascurabile, soprattutto in 
reti ben strutturate.
Ma queste sono le mie esperienze, che non debbono necessariamente valere per 
tutti.
Ciao,
         Tosh. 

 tutti.
Direi che il tuo ragionamento non fa una piega e lo appoggio in pieno.
Però, toglimi una curiosità, se collego uno switch da 5 euro (che ha un
loop) ad un catalyst da 100.000, quale sarebbe la motivazione tecnica
per la quale il cisco balla?
Mi piacerebbe saperla, in modo da tutelarmi nel caso mi dovesse
capitare.
Perchè mi sembra strano, se è presente un loop, prima o poi transiterà
anche una BPDU, e se la porta è sotto bpduguard, dovrebbe venir messa
in shutdown. se non lo fa, da qualche parte c'è un problema. Mi
piacerebbe
sapere quale.

per la quale il cisco balla?
In un loop circolano solo dei broadcast, visto che sono gli unici pacchetti 
che in uno switch possono arrivare dalle altre porte, dato che ovviamente le 
due porte in loop non possono generare traffico proprio, il risultato è un 
bel broadcast storm, che inevitabilmente si propaga su tutta la rete.
Mi è capitato di vedere una rete di quasi 1000 porte collassata per ore 
perchè un magazziniere si era portato un suo 3com da casa e un bel giorno 
qualcuno ha pensato di attaccare a quello switch una patch che penzolava 
facendo un bel loop.
Cisco ha la ovviamente a soluzione anche per quello, anzi più di una, ma 
questi sono decisamente casi limite che non dovrebbero accadere.
Ciao,
         Tosh.

 questi sono decisamente casi limite che non dovrebbero accadere.
A quali soluzioni fai riferimento?

A quali soluzioni fai riferimento?
Beh, innanzi tutto si potrebbe usare il "port secure" per fare in modo che 
ad ogni singola porta si possa associare solo un mac addres, poi esiste il 
comando "storm-control" che permette di fissare una soglia massima di 
broadcast (ma anche unicast e multicast) che possono transitare da una 
determinata porta.
Il primo di fatto impedisce l'utilizzo di switch attaccati a porte access, 
ma credo che possa fare a pugni con chi installa sistemi di virtualizzazione 
sui client.
Il secondo limita gli effetti di un broadcast storm.
Ciao,
         Tosh. 

 Il secondo limita gli effetti di un broadcast storm.
Uhm, secondo te quale può essere un valore 'giusto' ?
Non vorrei che limitare i broadcast legittimi possa portare a qualche
malfunzionamento di alcuni protocolli (sopratutto se lo stesso comando
dovesse limitare in automatico anche i multicast. Rischi di smontare
STP e VRRP, per dirne alcuni)

 reti ben strutturate.
Il problema è proprio questo: le reti ben strutturate, che sono -IMHO-
una discreta rarità.
IMHO quel che fa molto testo è la percentuale di utilizzo medio degli
uplink.
In reti in cui il L2 è prettamente locale e ben dimensionato per
l'utilizzo, la riduzione degli unicast-flood dovuti a topology change è
utile solo relativamente: a quel punto il grosso vantaggio del portfast
è l'immediatezza di utilizzabilità delle porte.
Se però gli uplink sono "tirati", le cose cambiano parecchio.
Ho un cliente che ha reti L2 distribuite geograficamente (rete
complessiva con ~1300 switch, raggruppati in una dozzina di reti L2
interconnesse via MPLS; ergo installazioni con oltre un centinaio di
switch nello stesso L2), con link SDH, modem RAD e cianfrusaglie simili
ad appiccicare il tutto in un unico calderone, in cui i link verso sedi
remote è spesso a 2Mbit.
Se (quando..) ci sono fenomeni di unicast-flood su una rete del genere
(e, viste le dimensioni della rete, significa anche "spesso"), quei link
-ovviamente- si siedono.
Un sapiente uso di portfast permetterebbe di tenere seriamente sotto
controllo la problematica (se solo il cliente volesse saperne di farlo).
E' indubbio che lì il limite è la inadeguata progettazione della rete (e
la mancanza di una segmentazione L3 adeguata alle problematiche della
stessa)...


Ciao a tutti.
Vorrei capire quali sono i vantaggi e gli svantaggi effettivi nell'uso dello 
spanning-tree portfast sulle porte. A quanto ho capito la sua abilitazione è 
potenzialmente pericolosa perché l'apparato non farà tutti i necessari 
controlli prima di uppare la porta e quindi un loop potrebbe buttarmi giù 
tutto. Se lo disattivo invece, perderò 20/30 secondi di tempo prima di avere 
la porta su, ma ci posso attaccare sopra di tutto.
Ora, da chi ha esperienza vissuta sul campo, vorrei capire se si trae 
effettivo beneficio da questo portfast, perché così come me lo sono 
immaginato ha più vantaggi che svantaggi.
Oppure il portfast ha la sua vera utilità se ci sono dei problemi di 
comunicazione tra host e switch perché evita che la porta debba perdere 
tempo a rinegoziarsi mantenendo il link su? In questo caso sarebbe 
assolutamente necessario impostarlo, soprattutto su link critici.
Grazie a chiunque voglia illuminarmi!
Bye
giaconet 

Non quoto e mi appendo qui solo per ringraziare tutti.
Leggendo tutti i vostri messaggi mi sono fatto una cultura in merito e devo 
dire che questo mondo è proprio affascinante.
All'inizio avevo paura di aver innescato un flame su una religion war, ma il 
tono è sempre stato pacatissimo.
Giusto per collocare la domanda in un contesto, stiamo parlando di una rete 
stellare in cui il nodo di campus è un 6509, i nodi di edificio sono 5 4507 
e gli apparati di accesso sono dei 3750. In tutto circa 1600 punti attivi.
La rete è L3, ma con una segmentazione, secondo il mio parere, scarsa. La 
VLAN1 di default "possiede" l'80% dei client e soprattutto è in uso un 
indirizzamento statico per gli IP, cosa pazzesca per queste dimensioni 
(IMHO).
Io vorrei proporre una migrazione ad un sistema L3 un pochino più 
articolato, in cui le zone di competenza dei 4500 siano in DHCP con 
indirizzamenti diversi (5 sottoreti e quindi domini di broadcast differenti) 
alle quali affiancare le vecchie VLAN da far propagare laddove ce ne fosse 
la reale necessità.
In ogni caso laddove è impostato lo spanning-tree portfast è sempre anche 
abilitato spanning-tree bpduguard enable (anche se ho capito che questo non 
basta ad assicurarsi sempre il perfetto funzionamento della rete, fantastico 
l'esempio dello switch con 2 porte in loop uplinkato ad un cisco :-D)
Cmq sto cercando di mappare la rete nei punti critici e abilitare il 
portfast laddove sono certo al 100% ci siano host (ad esempio i server) e 
disabilitare il portfast laddove abbia sospetti o certezze di cagate varie 
(switchini e switchetti da 5, 10, 80, 300 euro :-DDD)
Penso che seguirò spesso questo ng!!
Bye e grazie
giaconet 





 STP e VRRP, per dirne alcuni)
Penso che la cosa migliore consista nel monitorare via snmp il rapporto 
unicast/non-unicast quando la rete è in condizioni normali e fissare il 
broadcast-limit di conseguenza.

 remote č spesso a 2Mbit.
Ti offendi se ti dico che una rete del genere non fa media?
Non commento perchč so che spesso le situazioni non ottimali sono figlie di 
tanti padri, ma mi meraviglio veramente che una rete del genere possa stare 
in piedi.
Ciao,
        Tosh.

 in piedi.
Ci sta, con un sacco di problemi...


Uhm, secondo te quale può essere un valore 'giusto' ?
Questo è il punto, non esiste lo strumento perfetto, quello che ti 
garantisca da tutte le situazioni senza penalizzarti nell'operatività.
Poi non dimentichiamo che ogni funzione attiva chiede il suo tributo in 
termini di cpu dello switch, cosa che si tende spesso a dimenticare e che a 
volte diventa la causa dei problemi.
Tornando a noi Cisco consiglia di bloccare i broadcast al 5%, non so se sia 
corretto in tutte le situazioni.
Ciao,
         Tosh. 

 conseguenza la porta in BLOCKING come self-looped.
Ecco, questo fila e spiegherebbe tutto.

  satura di broadcast e le bpdu non passano pi.
Un po come dice Marco Giuliani, quindi...
Ok, ora mi è chiaro, ed in effetti, il discorso fila.







Bye e grazie
giaconet 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it