ARGOMENTO:

CAPITOLI 9-10 CCNP SWITCH - Advanced STP

Ciao Virgilio,
una prima domanda (ho visto 1 ora e mezza di registrazione ed ancora non ho trovato una risposta): nel caso di RSTP, abbiamo visto che lo stato delle porte viene calcolato in maniera sequenziale switch dopo switch con il meccanismo proposalagreement a 'scendere' (RST synch), ma non ho capito come avviene il calcolo del ROOT Bridge e del Secondary Root Bridge;
inoltre, nel caso di CST abbiamo ogni SWITCH che si propone cone ROOT prima di cominciare a mettere le porte in ROOT/DES/BLK, invece in RSTP non capisco, a questo punto, come avvenga l'elezione delle porte ROOT e BLK.

Grazie

un'altra cosa:
dopo averla riascoltata per 5 volte posso dire che non ho assolutamente capito come funziona ROOT GUARD, e ti chiedo per favore di spiegarmelo con un esempio diverso e con parole diverse, se ti è possibile;

Paolo_Tesse ha scritto: nel caso di RSTP, abbiamo visto che lo stato delle porte viene calcolato in maniera sequenziale switch dopo switch con il meccanismo proposalagreement a 'scendere' (RST synch), ma non ho capito come avviene il calcolo del ROOT Bridge e del Secondary Root Bridge;
inoltre, nel caso di CST abbiamo ogni SWITCH che si propone cone ROOT prima di cominciare a mettere le porte in ROOT/DES/BLK, invece in RSTP non capisco, a questo punto, come avvenga l'elezione delle porte ROOT e BLK.

L'elezione del Root Bridge per il RSTP avviene sostanzialmente allo stesso modo del CST, e come per CST ogni switch può stabilire la sua Root Port. Ciò che cambia è la modalità in cui vengono decise porte in stato di Blocking o di Forwarding, e questo avviene con il meccanismo delle proposte e risposte.

Paolo_Tesse ha scritto: non ho assolutamente capito come funziona ROOT GUARD

Il Root Guard è una funzionalità che può essere abilitata sulla porta di uno switch, questa mette la porta in inconsistent root state nel caso in cui sulla porta venga ricevuta una superior BPDU, vale a dire, viene connesso uno switch che si propone come Root questa porta viene sostanzialmente bloccata.

Vale la pena dire che lo stato di blocco della porta (root-inconsistent state) non è come nel caso di err-disable uno stato che di default richieda un intervento manuale, questo stato è in tutto simile allo stato di listening e viene corretto automaticamente nel momento in cui la porta smette di ricevere superior BPDU.

Puoi esaminare questo link per ulteriori dettagli

Grazie, una domanda anche su UDLD: in normal mode attende 3 volte il messagre time (default 15 secondi) prima di mettere in err-disable la porta; in aggressive mode invia una ECHO REQUEST al secondo per 8 volte, quindi se non riceve risposta mette la porta in err-disable; gli 8 secondi sono + il tempo che passa per il normal mode o si passa da 45 secondi (al minimo 21 secondi se si imposta a 7 il MESSAGETIME) a 8 secondi per passare ad err-disable la porta su cui viene rilevato un link unidirezionale?

Paolo_Tesse ha scritto: Grazie, una domanda anche su UDLD: in normal mode attende 3 volte il messagre time (default 15 secondi) prima di mettere in err-disable la porta; in aggressive mode invia una ECHO REQUEST al secondo per 8 volte, quindi se non riceve risposta mette la porta in err-disable; gli 8 secondi sono + il tempo che passa per il normal mode o si passa da 45 secondi (al minimo 21 secondi se si imposta a 7 il MESSAGETIME) a 8 secondi per passare ad err-disable la porta su cui viene rilevato un link unidirezionale?

Dunque, UDLD richiede 3 hello time interval senza risposta per fare detection di unidirectional link, quindi questo tempo può variare da 3 a 270 secondi poichè questo tempo è settabile tra 1 e 90 secondi. Se in aggressive mode, una volta fatta detection del link unidirezionale per 8 secondi prova a ristabilire la connessione con il neightboar una volta al secondo. Questo vuol dire che in aggressive mode il tempo minimo di disabilitazione della porta è di 11 secondi, tempo che può risultare troppo lungo per alcune implementazioni RSTP.