Spanning-tree dylemat

Pytania dt. certyfikacji CCNA i CCDA
Wiadomość
Autor
m3rlin

Spanning-tree dylemat

#1

#1 Post autor: m3rlin »

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

Awatar użytkownika
balam
wannabe
wannabe
Posty: 977
Rejestracja: 21 cze 2006, 16:27
Lokalizacja: Warszawa

#2

#2 Post autor: balam »

To powinno Ci wyjasnic watpliwosci :P

Awatar użytkownika
kktm
CCIE
CCIE
Posty: 2025
Rejestracja: 20 paź 2004, 14:43
Lokalizacja: Wrocław

#3

#3 Post autor: kktm »

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.
"Trust no one"

Awatar użytkownika
polak
wannabe
wannabe
Posty: 294
Rejestracja: 20 mar 2005, 14:23
Lokalizacja: Bruksela

#4

#4 Post autor: polak »

dokladnie jak napisal kktm tyle, ze B po wykryciu awarii lacza nie bedzie czekal tych domyslnych 20s.
(jakby na B byl uplinkfast to trwalo by to 1-5s chociaz do konca nie wiem bo port blocking jest na C a nie na B ).
King Kong ain't got shit on me!

Awatar użytkownika
digit
wannabe
wannabe
Posty: 148
Rejestracja: 19 maja 2005, 22:05

#5

#5 Post autor: digit »

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 ;)

Awatar użytkownika
polak
wannabe
wannabe
Posty: 294
Rejestracja: 20 mar 2005, 14:23
Lokalizacja: Bruksela

#6

#6 Post autor: polak »

digit 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.
Jesli link na B bedzie down to nie bedzie czekal tych 20s. Jesli bedzie up a tylko BPDU nie
beda przechodzily (jakies filtrowanie) to odczeka te 20s. :)
King Kong ain't got shit on me!

Awatar użytkownika
kktm
CCIE
CCIE
Posty: 2025
Rejestracja: 20 paź 2004, 14:43
Lokalizacja: Wrocław

#7

#7 Post autor: kktm »

polak pisze:
digit 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.
Jesli link na B bedzie down to nie bedzie czekal tych 20s. Jesli bedzie up a tylko BPDU nie
beda przechodzily (jakies filtrowanie) to odczeka te 20s. :)
Dokladnie zgadzam sie z przedmowca :)

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"

m3rlin

#8

#8 Post autor: m3rlin »

No racjaaa !.... zupelnie nie pomyslalem o tym, ze B bedzie probowal zrobic z siebie roota :-)
No to teraz sprawa jasna... thx chlopaki !

Awatar użytkownika
galus
member
member
Posty: 25
Rejestracja: 22 wrz 2005, 09:41
Lokalizacja: Polska, Bydgoszcz

#9

#9 Post autor: galus »

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 
Dokladnie, przy czym nie tak natychmiast.
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.

ODPOWIEDZ