Spanning-tree dylemat
Spanning-tree dylemat
Witajcie,
analizowalem ostatnio zasade dzialania STP i zastanowila mnie jedna sprawa.
http://aaa1.za.pl/
Na rysunkach mamy dwie sytuacje, jedna jest dla mnie jasna... awaria lacza, root wysyla TCN i po pewnym czasie switch C dostaje to BPDU i ustawia nowy root port.
Zastanawiam sie co bedzie, jesli tym razem zablokowany port bedzie po drugiej stronie.
Wiele sie niby nie zmieni, podobnie root wysle BPDU TCN, ale teraz pytanie... czy C wysle to BPDU dalej ? zeby B mogl wyznaczyc nowy root port ?
Pytam poniewaz C ma port w stanie "blocking" (zakladajac, ze literki wskazuja na priorytet) czyli jesli dobrze to "przetrawilem" wolno mu TYLKO odbierac BPDU. Skoro nie wysle, to jak B sie dowie o nowej sciezce do roota ?
Pozdro
analizowalem ostatnio zasade dzialania STP i zastanowila mnie jedna sprawa.
http://aaa1.za.pl/
Na rysunkach mamy dwie sytuacje, jedna jest dla mnie jasna... awaria lacza, root wysyla TCN i po pewnym czasie switch C dostaje to BPDU i ustawia nowy root port.
Zastanawiam sie co bedzie, jesli tym razem zablokowany port bedzie po drugiej stronie.
Wiele sie niby nie zmieni, podobnie root wysle BPDU TCN, ale teraz pytanie... czy C wysle to BPDU dalej ? zeby B mogl wyznaczyc nowy root port ?
Pytam poniewaz C ma port w stanie "blocking" (zakladajac, ze literki wskazuja na priorytet) czyli jesli dobrze to "przetrawilem" wolno mu TYLKO odbierac BPDU. Skoro nie wysle, to jak B sie dowie o nowej sciezce do roota ?
Pozdro
IMHO (choc moge sie mylic )
1. cat B stracil dostep do root-bridge.
2. Po 20 sekundach braku otrzymywania BPDU od roota, cat B mysli ze jest rootem i wysyla ramki bpdu podajac sie za root do cat C
3. cat C widzi ze cat B nijak sie nie styka z rootem, cat B przedstawial sie jako root wiec logiczne jest ze nic do niego nie jest podlaczone. Port w stanie blocking co prawda nie wysyla BPDU, ale je odbiera
4. cat C mysli jak ja , w tym segmienicie stwierdzil ze cat B nie ma dostepu do root wiec designated/block port nie ma miejsca i port przechodzi w stan forward
indirect-failure- calkowity czas rekonwergencji- 50 s.
1. cat B stracil dostep do root-bridge.
2. Po 20 sekundach braku otrzymywania BPDU od roota, cat B mysli ze jest rootem i wysyla ramki bpdu podajac sie za root do cat C
3. cat C widzi ze cat B nijak sie nie styka z rootem, cat B przedstawial sie jako root wiec logiczne jest ze nic do niego nie jest podlaczone. Port w stanie blocking co prawda nie wysyla BPDU, ale je odbiera
4. cat C mysli jak ja , w tym segmienicie stwierdzil ze cat B nie ma dostepu do root wiec designated/block port nie ma miejsca i port przechodzi w stan forward
indirect-failure- calkowity czas rekonwergencji- 50 s.
"Trust no one"
Dorzuce cos od siebie. 802.1d
1. CATB poprzez przestanie otrzymywania BPDU od roota na porcie 1/1, odczekuje Max Age (default 20s) po czym zaczyna reagowac. CAT B ustaiwa port 1/1 w stan blocking bo nic nie otrzymuje (pewnie uszkodzenie fizyczne) i decyduje sie na ogloszenie siebie rootem.
2. Wyslane przez Cat B BPDU na port 1/2 trafia do portu 1/2 CAT C (w stanie blocking switch nasluchuje przychodzacych BPDU). Jednoczesnie z drugiej strony otrzymuje BPDU od root'a z lepszym bridge ID.
3. CAT C postanawia przeforwardowac lepsze BPDU na port 1/2. Ustawia port 1/2 w stan listening na czas forward delay (d.15s) oraz wysyla na ten port TCN. Po stanie listening, port 1/2 cat C przechodzi w stan learning na kolejny Forward delay. Pozniej przchodzi w stan forward, bo juz w stanie listetning wiedzial, ze od CAT B nie dochodza zadne BPDU => nie ma designated bridge'a, nie ma deignated port'a. Cat B otrzymuje BPDU z wyzszym od swojego ID i przestaje rozglaszac siebie jako roota, flushuje tablice macow.
Calkowity czas rekonwergencji 20 (maxAge) + 15(listening) + 15(learning) = 50s.
Chyba jakos tak to szlo
1. CATB poprzez przestanie otrzymywania BPDU od roota na porcie 1/1, odczekuje Max Age (default 20s) po czym zaczyna reagowac. CAT B ustaiwa port 1/1 w stan blocking bo nic nie otrzymuje (pewnie uszkodzenie fizyczne) i decyduje sie na ogloszenie siebie rootem.
2. Wyslane przez Cat B BPDU na port 1/2 trafia do portu 1/2 CAT C (w stanie blocking switch nasluchuje przychodzacych BPDU). Jednoczesnie z drugiej strony otrzymuje BPDU od root'a z lepszym bridge ID.
3. CAT C postanawia przeforwardowac lepsze BPDU na port 1/2. Ustawia port 1/2 w stan listening na czas forward delay (d.15s) oraz wysyla na ten port TCN. Po stanie listening, port 1/2 cat C przechodzi w stan learning na kolejny Forward delay. Pozniej przchodzi w stan forward, bo juz w stanie listetning wiedzial, ze od CAT B nie dochodza zadne BPDU => nie ma designated bridge'a, nie ma deignated port'a. Cat B otrzymuje BPDU z wyzszym od swojego ID i przestaje rozglaszac siebie jako roota, flushuje tablice macow.
Calkowity czas rekonwergencji 20 (maxAge) + 15(listening) + 15(learning) = 50s.
Chyba jakos tak to szlo
Jesli link na B bedzie down to nie bedzie czekal tych 20s. Jesli bedzie up a tylko BPDU niedigit pisze: 1. CATB poprzez przestanie otrzymywania BPDU od roota na porcie 1/1, odczekuje Max Age (default 20s) po czym zaczyna reagowac. CAT B ustaiwa port 1/1 w stan blocking bo nic nie otrzymuje (pewnie uszkodzenie fizyczne) i decyduje sie na ogloszenie siebie rootem.
beda przechodzily (jakies filtrowanie) to odczeka te 20s.
King Kong ain't got shit on me!
Dokladnie zgadzam sie z przedmowcapolak pisze:Jesli link na B bedzie down to nie bedzie czekal tych 20s. Jesli bedzie up a tylko BPDU niedigit pisze: 1. CATB poprzez przestanie otrzymywania BPDU od roota na porcie 1/1, odczekuje Max Age (default 20s) po czym zaczyna reagowac. CAT B ustaiwa port 1/1 w stan blocking bo nic nie otrzymuje (pewnie uszkodzenie fizyczne) i decyduje sie na ogloszenie siebie rootem.
beda przechodzily (jakies filtrowanie) to odczeka te 20s.
Pada kabel to widza to 2 strony. Czyli nie 20 sekund, a natychmiast.
Olac bpdu hello co 2 sek, bo i tak swich widzi ze mu linia padla.
No chyba ze padnie tylko 1 para- ale panowie dajmy juz spokoj- wiadomo o co chodzi
"Trust no one"
Kod: Zaznacz cały
Cat C widzi ze cat B nijak sie nie styka z rootem, cat B przedstawial sie jako root wiec logiczne jest ze nic do niego nie jest podlaczone. Port w stanie blocking co prawda nie wysyla BPDU, ale je odbiera
4. cat C mysli jak ja :) , w tym segmienicie stwierdzil ze cat B nie ma dostepu do root wiec designated/block port nie ma miejsca i port przechodzi w stan forward
B wysyla BPDU, ze jest rootem.
C odbiera (inferior BPDU), ale to ignoruje, bo ma lepsza sciezke do roota.
B przestaje przesylac (relay) BPDU do segmentu C-B (bo stracil kontakt z rootem)
C to "zauwaza" i po uplywie 20 s przelacza port w Lis->Lear->Forw.
... a dalej tak jak napisales.
btw: backbone fast (jesli dobrze pamietam) ma za zadanie skrocic ten czas o te 20 s.