Więcej

    Maszyna stanowa OSPF

    Umiejętność konfiguracji protokołów sieciowych jest nieoceniona. Niemniej jednak prawdziwą wartość stanowi umiejętność ich troubleshootingu gdy coś pójdzie nie tak. Nie oszukujmy się – bez poznania wewnętrznych mechanizmów rządzących działaniem poszczególnych protokołów, błądzimy niczym dzieci we mgle, szukając powodu usterki. Przyjrzyjmy się dziś działaniu maszyny stanowej (ang. state machine) protokołu OSPF. Zapraszamy do materiału wideo na początku tego artykułu oraz do notatek poniżej.

    Maszyna stanowa OSPF jest niczym innym jak cyklem stanów, przez które przechodzi protokół w trakcie swojego normalnego działania. Zrozumienie działania poszczególnych stanów oraz okoliczności, w których one występują pozwala nam zatem się bardzo dobrze zorientować w sytuacji. Spójrzmy najpierw jak została ta kwestia ujęta w RFC 2328 z 1998 roku.

    Maszyna stanowa OSPFv2 w RFC 2328

    Informację w postaci diagramu znajdujemy na stronie 83. oraz 84. dokumentu RFC 2328. Prezentuje się ona następująco:

    Widzimy tutaj stany związane z wymianą pakietów Hello i nawiązaniem wstępnej relacji sąsiedztwa. Przechodzimy zatem od stanu Down, aż do ExStart, w którym to inicjujemy wymianę tras. Warto zwrócić uwagę w tej części na trzy elementy:

    • początkowe stany Down, Attempt oraz Init – a przede wszystkim okoliczności, w których one występują,
    • możliwość „cofnięcia się” maszyny stanowej ze stanu 2-Way do Init w przypadku utraty pakietów Hello od neighbora (mamy wtedy notabene do czynienia z komunikacją 1-Way),
    • listę niektórych zdarzeń powodujących zmianę stanów.

    Kolejna strona RFC precyzuje z kolei dalszą część maszyny stanowej:

    W tej części widzimy dalsze postępowanie procesu, od stanu ExStart, aż do Full. Lista zdarzeń tym razem jest nieco dłuższa.

    Tabela poniżej listuje wszystkie stany (z pominięciem Attempt, którego w zasadzie nigdy nie dostrzeżemy w trakcie działania OSPF na danym urządzeniu). Każdy ze stanów jest również pokrótce scharakteryzowany.

    Przyjrzyjmy się teraz bliżej poszczególnym stanom. Na potrzeby naszych rozważań załóżmy, że obserwujemy sytuację z perspektywy R1.

    Down & Init

    Uruchomienie OSPF powoduje przejście ze stanu Down w stan Init. To w tym stanie zaczynamy wysyłanie pakietów Hello. Celem wysyłania pakietów Hello jest wykrycie innych sąsiadów (neighborów) na danym łączu.

    Jeżeli sąsiadujący z nami router otrzyma nasz pakiet Hello (i wszystkie atrybuty, które muszą być zgodne będą… zgodne) to doda on nas do swojej listy sąsiadów (neighbor list).

    Kluczowy jest tu fakt, że każdy pakiet Hello zawiera listę sąsiadów danego routera.

    2-Way

    Gdy otrzymamy od R2 „zwrotny” pakiet Hello, powinien on zawierać nasz własny router-ID na liście sąsiadów. Dodajemy zatem R2 na naszą własną listę sąsiadów i przechodzimy do stanu 2-Way.

    Gratulacje! Nawiązaliśmy dwukierunkową relację sąsiedztwa. Jest to dobry moment, aby zwrócić uwagę na to, że istnieje sytuacja, w której maszyna stanowa zatrzyma się na tym stanie (2-Way) i nie pójdzie dalej (w związku z czym z sąsiadem nie wymienimy tras).

    Sytuacja taka ma miejsce gdy łączymy nasze routery w rozgłoszeniowym segmencie sieci (takim jak sieci Ethernet łączone np. przełącznikami). Przy pięciu routerach będziemy już mieli do czynienia z dużą ilością pełnych stanów zbieżności (dokładnie n(n-1)/2, gdzie n jest ilością routerów), które musielibyśmy nawiązać. Zmiana bądź strata trasy na jednym z tych routerów wyzwalałaby całą falę aktualizacji, które pochłaniałyby dość sporo przepustowości naszej sieci.

    Rozwiązaniem tego problemu jest elekcja routerów DR oraz BDR. Jest to temat wykraczający poza ten materiał, ale pokrótce wspomnę, że sam proces elekcji DR i BDR oparty jest o system priorytetów. Najwyższy priorytet wygrywa, a brane są pod uwagę po kolei: statycznie konfigurowany priorytet (domyślna wartość 1), a następnie najwyższy router-ID.

    Routery DR oraz BDR nawiążą ze wszystkimi innymi routerami w segmencie Ethernet pełny stan zbieżności (Full) i wymienią z nimi trasy. Natomiast wszystkie pozostałe routery (które nazywamy DROTHER) nawiążą między sobą sąsiedztwo w stanie 2-Way – i na nim się zatrzymają! Będą neighborami – ale nie będą wymieniać tras.

    Weź pod uwagę, że jeśli połączysz ze sobą bezpośrednio dwa routery na interfejsach Ethernetowych (tak jak ma to miejsce na przykładzie powyżej) to będzie to z perspektywy OSPF nadal segment broadcastowy i mechanizm elekcji DR oraz BDR będzie miał miejsce. Wynika to bezpośrednio z interfejsów na jakich zestawiliśmy nasze połączenia (w tym przykładzie Gigabit Ethernet). Na interfejsach Serial ta sytuacja by nie wystąpiła.

    Aby pozbyć się elekcji DR i BDR na łączu point-to-point zestawionym na interfejsach Ethernet, należy na poziomie tychże interfejsów wydać komendę: ip ospf network point-to-point

    ExStart

    Czas pójść o krok dalej. Mamy nawiązaną relację sąsiedztwa. Wszystkie routery na połączeniach point-to-point oraz routery DR i BDR w segmentach broadcastowych przechodzą teraz do kolejnego stanu – ExStart. Jest to nic innego jak start procesu synchronizacji LSDB (link state database) pomiędzy routerami.

    Warto zwrócić uwagę, że proces synchronizacji zaczyna router z najwyższym router-ID. To on jako pierwszy wyśle swoje DBD – czyli Database Descriptor. DBD jest swego rodzaju streszczeniem danych zawartych w LSDB (chcemy zaoszczędzić na przepustowości – po co wysyłać wszystkie szczegółowe trasy skoro sąsiad część z nich może już mieć?).

    Exchange

    Kolejny stan to Exchange. Tutaj kontynuujemy opisaną wcześniej wymianę pakietów DBD – tak długo aż oba routery nie prześlą deskryptorów dla całej zawartości swoich LSDB.

    Loading & Full

    Po zakończeniu wymiany DBD przechodzimy do stanu Loading. Nasz router R1 sprawdza informacje zawarte w DBD otrzymanych od R2 i porównuje ich zawartość ze swoją bazą LSDB. W rezultacie takiego porównania R1 będzie w stanie stwierdzić jakich prefiksów mu brakuje (innymi słowy o jakich nowych sieciach wie R2).

    Zaczyna się teraz wymiana pakietów LSR (Link State Request) oraz LSU (Link State Updates). Requesty są prośbami o wysłanie szczegółów dotyczących nowych dla R1 prefiksów. R2 odpowiada za pomocą LSU, które mogą zawierać jeden lub więcej pakietów LSA (Link State Advertisement). Każdy LSA jest szczegółowym rekordem dotyczącym konkretnej trasy. No i w końcu – każdy nie każdy LSU musi zostać potwierdzony za pomocą LSAck (Link State Acknowledgement) – tutaj odsyłam pod artykuł do pouczającego komentarza autorstwa Macieja.

    Gdy wszystkie informacje na temat tras zostaną uzupełnione, routery dochodzą do stanu, w których ich LSDB są w pełni zsynchronizowane. Osiągnęliśmy stan Full. I dokładnie o to nam w OSPF chodzi 🙂

    Masz jakieś uwagi do wpisu? A może coś byś dodał? Podziel się w komentarzu!

    🗳 Jak przydatna była ta publikacja?

    Średnia ocena 4.7 / 5. Ilość głosów: 3

    Brak ocen. Bądź pierwszy!

    Dziękujemy za ocenę! Zapraszamy Cię do obserwowania NSS w mediach społecznościowych!

    Przykro nam, że ta publikacja okazała się być dla Ciebie nieprzydatna!

    Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

    Jak możemy poprawić tę publikację?

    Damian Michalak
    Network Consultant, Twórca Na Styku Sieci

    6 KOMENTARZE

    guest
    6 - Ilość komentarzy
    Sortuj wg najstarszych
    Sortuj wg najnowszych Sortuj wg najlepszych
    Inline Feedbacks
    View all comments
    Maciej

    LSAck potwierdza otrzymanie LSA, nie samego LSU. Potwierdzenie jest potrzebne żeby wyrzucić LSA z listy retransmisji ;).

    Taka ciekawostka, nie każde LSA musi zostać potwierdzony przez LSAck (explicit ack), kopia otrzymanego LSA w otrzymanym LSU od sąsiada również może posłużyć jako potwierdzenie (implicit ack).

    Maciej

    Heh, to raczej nie jest faux pas, gdyż rzadko kto zwraca uwagę na same LSAck, a co dopiero na piggybacking LSU.

    Generalnie jestem w stanie wymyślić tylko 1 scenariusz gdzie ten mechanizm jest używany zgodnie z założeniem:

    • DROTHER wysyła LSU => DR/BDR zalewa pseudo-node tym samym LSU (ale oczywiście na inny address multicast) => DROTHER otrzymuje swoje LSA od DR/BDR i wyrzuca je z listy retransmisji.

    Pewno można by pokusić się o próbę podciągnięcia pewnych race conditions dla sytuacji \”LSA has been flooded back out receiving interface\”, może gdy topologią to pierścień.

    Bruno

    Ekstra artykuł, dużo rozjaśnił. Dzięki Damian!

    Przygotowujesz się do certyfikacji CCNA?

    Zapisz się na nasz NSSletter, a co tydzień we wtorek rano otrzymasz porcję sieciowej wiedzy oraz porady dotyczące certyfikacji.

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    133ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    6
    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x