(T) Nawiązywanie relacji sąsiedztwa protokołu OSPF

Nawiązywanie relacji sąsiedztwa protokołu OSPF

Nawiązywanie relacji sąsiedztwa

Warunki nawiązania relacji sąsiedztwa

  • Aby routery nawiązały ze sobą relację sąsiedztwa, muszą spełniać następujące kryteria:
Wymagania dotyczące relacji sąsiedztwa EIGRP OSPF
Sąsiedzi muszą być wstanie wysyłać pomiędzy sobą pakiety IP Tak Tak
Adresy IP muszą należeć do tej samej sieci Tak Tak
Interfejsy nie mogą działać w trybie pasywnym Tak Tak
Sąsiedzi muszą należeć do tego samego systemu autonomicznego ASN (EIGRP) bądź procesu „process-ID” (OSPF) Tak Nie
Czasy hello oraz Hold (EIGRP), Dead (OSPF) muszą się zgadzać Nie Tak
Sąsiedzi muszą przejść proces autentykacji (Jeżeli przynajmniej jedno z urządzeń takiego wymaga) Tak Tak
Sąsiedzi muszą należeć do tej samej strefy Area (OSPF). N/A Tak
Wartość IP MTU musi się zgadzać Nie Tak
Wartość K-value musi być taka sama Tak N/A
Wartość Router ID musi być unikalna Przeważnie nie Tak
Wymagania dotyczące procesu nawiązywania relacji sąsiedztwa dla protokołu OSPF / EIGRP
W przypadku kryterium „Adresy IP muszą należeć do tej samej sieci” logika postępowania protokołu OSPF różni się od logiki postępowania protokołu EIGRP. OSPF porównuje całą wartość adresu oraz maski sąsiedniego urządzenia, natomiast EIGRP patrzy jedynie na to czy adres IP sąsiada należy do tej samej sieci co lokalny interfejs. Przykładowo sąsiednie urządzenie z skonfigurowanym adresem [ip address 192.168.10.2 255.255.255.252] nawiąże relacje sąsiedztwa z interfejsem o adresie [ip address 192.168.10.1 255.255.255.0] w przypadku protokołu EIGRP, ale nie OSPF.

Nazewnictwo związane z procesem nawiązywania relacji sąsiedztwa

  • DR (Designated Router) – Główne urządzenie otrzymujące struktury LSA typu pierwszego, od sąsiednich ruterów znajdujących się obrębie jednej sieci wielodostęp-owej. W celu ich przetworzenia a następnie rozesłania do sąsiednich urządzeń, w postaci struktur LSA typu drugiego (W obrębie jednej sieci wielodostęp-owej).
  • BDR (Buckup Designated Router) – Ruter zapasowy, przejmujący rolę aktywną w przypadku awarii rutera DR (Również otrzymuje struktury LSA typu pierwszego, od sąsiednich ruterów znajdujących się obrębie jednej sieci wielodostęp-owej. Jednak na nie nie odpowiada).
  • DROther – Pozostałe rutery znajdujące się w sieci wielodostęp-owej (Nie pełniące roli DR-a bądź BDR-a).
  • Stan Adjacent – Osiągają rutery DROther w relacji z innymi urządzeniami działającym w trybie DROther (Ponieważ nie osiągają one pełnej relacji sąsiedztwa, a jedynie tryb Two-Way State).
  • Stan Fully Adjacent – Osiągają rutery: DR w relacji z BDR, DR z DROther oraz BDR z DROther (Wszystkie wymienione kombinacje osiągają pełny status relacji sąsiedztwa Full State).

Przyczyny procesu elekcji rutera DR oraz BDR

  • Sieci wielodostęp-owe takie jak „Broadcast multiaccess”, mogą wymagać nawiązanie wielu relacji sąsiedztwa, a ty samym spowodować wygenerowanie dużej liczby wiadomości aktualizacyjnych LSA, LSR czy LSU, zgodnie ze wzorem n (n-1)/2 (Z czego n stanowi ilość podłączonych do sieci ruterów).
  • Aby zapobiec powstaniu nadmiarowego ruchu sieciowego, rutery w obrębie jednej sieci wielodostęp-owej. Prowadzą elekcję urządzenia pełniącego rolę DR-a oraz BDR-a, na podstawie wymienianych pomiędzy sobą wiadomości „Hello”. Po zakończeniu procesu elekcji, do wybranego rutera DR/BDR kierowane są wszystkie wiadomości LSA typu pierwszego, nadchodzące od sąsiednich urządzeń. Następnie ruter DR rozsyła przetworzone przez siebie dane, za pomocą struktur LSA typu drugiego, niwelując tym samym potrzebę wymiany aktualizacji, bezpośrednio pomiędzy sąsiadami DROther. Ruter BDR nie bierze udziału w rozsyłaniu struktur LSA typu drugiego.
Inne rutery znajdujące się w sieci wielodostęp-owej nazywane są DROther. Nie osiągają one pomiędzy sobą pełnej relacji sąsiedztwa Full State a jedynie stan pośredni Two-way State (Stan Two-way State, oznacza że sąsiednie urządzenia nie wymieniły pomiędzy sobą informacji na temat zawartości bazy LSDB).

Elekcja rutera DR oraz BDR

  • Rolę aktywną (DR) przejmuje urządzenie z najwyższą wartością priorytetu (0255). Jeżeli wartość ta jest taka sama na wszystkich urządzeniach, pod uwagę brana jest najwyższa wartość RID (Router ID).
  • Urządzenie z drugą najwyższą wartością (Priorytetu / wartości RID) przejmuje rolę zapasową BDR.
  • Po zakończeniu elekcji urządzeń DR/BDR, ponowna elekcja może nastąpić jedynie w sytuacji awarii przynajmniej jednego z urządzeń pełniących rolę DR-a bądź BDR-a.
  • W przypadku utraty DR-a jego rolę przejmuje BDR niezależnie od tego czy w sieci istnieje urządzenia z większą wartością priorytetu czy też nie takowego nie ma.
  • Wartość priorytetu można skonfigurować za pomocą komendy [ip ospf priority 0-255] w trybie konfiguracji interfejsu sieciowego.

Stany protokołu OSPF

Nawiązywanie relacji sąsiedztwa

  • Down State – Początkowa faza procesu nawiązywania relacji sąsiedztwa. W większości przypadków urządzenia pozostają w tej fazie, kiedy to statycznie skonfigurowany sąsiad nie odpowiada na wiadomości powitalne „Hello”. Tego typu relacja z innym ruterem wskakuje, że lokalne urządzenie zna adres IP swojego sąsiada, ale nie może nawiązać z nim relacji sąsiedztwa, z powodu problemów związanych z np. komunikacją.
  • Attempt State – Stan występujący jedynie w sieciach „Nonbroadcast Multiaccess” NBMA, w przypadku statycznie skonfigurowanej relacji sąsiedztwa (Ruter wie o swoim sąsiedzie ale nie otrzymał od niego wiadomości powitalnej „Hello”).
  • Init State – Połączenie z sąsiednim ruterem zostaje przeniesione w stan „Init state” zaraz po otrzymaniu pierwszej wiadomości „Hello”, w której lista widocznych routerów (Active Neighbor) nie zawiera wartości RID lokalnego urządzenia. Co oznacza że jest ono w stanie wykryć swojego sąsiada, ale nie ma pewności czy samo jest dla niego widoczne.
  • Two-Way State – Połączenie z sąsiednim ruterem zostaje przeniesione w stan „Two-Way” zaraz po otrzymaniu pierwszej poprawnej wiadomości „Hello”, której lista widocznych routerów (Active Neighbor) zawiera wartości RID lokalnego urządzenia. Co oznacza, że obydwa urządzenia są dla siebie widoczne. Stan ten jest stanem stabilnym dla sąsiadów nie aspirujących do fazy „Full State”, np. w przypadku sieci wielodostęp-owych „Multiaccess” pomiędzy urządzeniami DROther.
Proces nawiązywania relacji sąsiedztwa
  • Powyższa grafika prezentuje przykładowy proces nawiązywania relacji sąsiedztwa, pomiędzy dwoma ruterami znajdującymi się w stanie „Down State”:
    1. Obydwa urządzenia wysyłają do siebie wiadomości powitalne „Hello”, na Multicast-owy adres IP (224.0.0.5, Init).
    2. Każdy z routerów weryfikuje otrzymaną od sąsiada wiadomość powitalną „Hello”, sprawdzając zgodność wszystkich parametrów wymaganych do nawiązania prawidłowej relacji sąsiedztwa.
    3. Obydwa urządzenia wysyłają kolejne wiadomości powitalne „Hello”, zawierające wartość RID sąsiedniego routera.
    4. Po otrzymaniu wiadomości „Hello” zawierającej wartość RID lokalnego jak i sąsiedniego urządzenia (W polu Active Neighbor). Relacja pomiędzy urządzeniami przechodzi w stan Two-Way State.
    5. Po osiągnięciu stanu „Two-Way State” rutery decydują, czy powinny nawiązać pełną relację sąsiedztwa, w oparciu o pełnione przez siebie role (DR, BDR bądź DROther). W przypadku topologii niewymagających elekcji rutera DR, każdorazowa odpowiedź na to pytanie będzie twierdząca.

Wymiana danych LSDB

  • ExStart State – Rutery przechodzą do stanu „ExStart State ze stanu „Init State bądź stanu „Two-Way State po potwierdzeniu wzajemnej widoczności jak i zdecydowaniu o należności nawiązania pełnej relacji sąsiedztwa, pomiędzy obydwoma urządzeniami. Podstawowym zadaniem stanu „ExStart State” jest nawiązanie relacji Master/Slave pomiędzy sąsiadami, za pomocą wiadomości „Database Description” zawierającej wartości RID, na postawie których wybierany jest ruter pełniący rolę Master-a (Większa wartość RID) oraz negocjowany jest startowy numeru sekwencyjny pierwszej struktury LSA.
  • Exchange State – Po nawiązaniu relacji Master/Slave pomiędzy sąsiadami, rutery przechodzą w stan „Exchange State”, w którym to obydwa urządzenia wymieniają pomiędzy sobą wiadomości „Database Description”, proces ten jest kontrolowany przez ruter pełniący rolę Master-a. Wiadomości DBD zawierają wartości LSID (Link State ID) oraz numery sekwencyjne wszystkich znanych struktur LSA z danej strefy (Area).
  • Loading State – Po zakończeniu wymiany informacji o wszystkich znanych strukturach LSA, relacja pomiędzy ruterami przechodzi w stan „Loading State”. Na tym etapie każdy z ruterów określa jakich struktur LSA, które posiada sąsiednie urządzenie mu brakuje. A następnie wysyła oddzielne wiadomości LSR względem każdej z brakujących struktur z osobna. W odpowiedzi na zapytanie LSR, sąsiednie urządzenie odsyła wiadomość LSU zawierającą brakujące struktury LSA, oczekując tym samym na potwierdzenie otrzymania wiadomości LSU za pomocą potwierdzenia ACK.
  • Full State – Po zakończeniu obopólnej wymiany danych, relacja sąsiedztwa przechodzi w stan „Full State”.
W stanie „Exchange State” wymianie ulegają jedynie dane LSID oraz numery sekwencyjne wszystkich struktur LSA. Tymczasem w wiadomościach LSU przesyłane są pełne kopie struktur LSA.
Wiadomości DBD, LSR oraz LSU są wymieniane pomiędzy ruterami za pomocą pakietów Unicast-owych.
Wiadomości LSU mogą być również wymieniane za pomocą pakietów Multicast-owych.
Proces wymiany informacji zawartych w bazie LSDB

Nawiązywanie relacji Master/Slave

  • Funkcja nawiązywania relacji Master/Slave, ma na celu skoordynowanie procesu wstępnej wymiany danych LSDB za pomocą wiadomości DBD. Ruter pełniący rolę Master-a zostaje wybrany na podstawie wartości RID. Przejmując tym samym role nadzorczą umożliwiającą mu inicjowanie wymiany wiadomości DBD, czy określanie wartości numeru sekwencyjnego dla struktur LSA. Tymczasem ruter pełniący rolę Slave, może jedynie odpowiadać wiadomościami DBD, na wysłane przez Master-a zapytania DBD.

Wymiana danych LSDB bez elekcji rutera pełniącego role DR

  • Po osiągnieciu stanu „Two-Way” obydwa rutery decydują, czy nawiążą ze sobą pełną relację sąsiedztwa, polegającą na wymianie danych zawartych w bazie LSDB. Jeżeli w sieci łączącej obydwa urządzenia nie zachodzi potrzeba elekcji rutera DR, BDR, odpowiedź jest zawsze twierdząca. W takiej sytuacji urządzenia postępują zgodnie z następującą logiką:
    • 1. Odkrywają struktury LSA znane sąsiadowi, ale nie znane jemu samemu.
    • 2. Odkrywają struktury LSA znane obydwóm ruterom, z czego te posiadane przez sąsiada są bardziej aktualne.
    • 3. Proszą sąsiedni ruter o kopie wszystkich brakujących bądź nie aktualnych struktur LSA, określonych w punkcie 1 oraz 2.
  • Po otrzymaniu pierwszej wiadomości DBD (Wysłanej na Multicast-owy adres IPv4 224.0.0.5) ruter przenosi relację sąsiedztwa w stan „ExStart State”, do momentu elekcji rutera pełniącego rolę Master, na podstawie większej wartości RID (Router ID).
  • Po określeniu roli Master-a, rutery kontynuują wymianę wiadomości DBD zawierających dane LSID oraz numery sekwencyjne wszystkich struktur LSA, w celu określenia powyższych punktów 1 oraz 2. Następnie relacja przechodzi w stan „Loading State” rozpoczynając następujący cykl zdarzeń:
    • Rutery wysyłają do siebie nawzajem zapytania LSR zawierające dane LSID, odpowiadające każdej z brakujących bądź nieaktualnych strukturze LSA, jakich same nie posiadają.
    • W odpowiedzi na zapytania LSR sąsiedni ruter wysyła odpowiedź LSU zawierającą pełną strukturę LSA.
    • Po otrzymaniu odpowiedzi LSU ruter potwierdza otrzymanie struktury LSA za pomocą wiadomości LSAck (Explicit Acknowledgment) bądź odsyłając otrzymaną wiadomość LSU (Implicit Acknowledgment).

Wymiana danych LSDB po elekcji rutera pełniącego role DR-a, BDR-a

  • Wymiana danych bazy LSDB, w sieci posiadającej rutery pełniące rolę DR-a oraz BDR-a, różni się od tego samego procesu zachodzącego w sieci nie wymagającej elekcji ruterów DR oraz BDR. Chodź nazewnictwo oraz znaczenie poszczególnych etapów jest takie samo, to wymiana danych pomiędzy niektórymi z ruterów może być ograniczona. Ponieważ pełną relację sąsiedztwa a co za tym idzie pełną wymianę danych LSDB, utrzymują jedynie rutery DROther z ruterami DR oraz ruterami BDR jak i rutery DR z ruterami BDR.
  • Proces działania wymiany danych bazy LSDB jest następujący:
  • Rutery DROther oraz rutery BDR wysyłają wiadomości DBD zawierające wartości LSID struktur LSA Typu pierwszego (LSA Type 1) na multicast-owy adres 224.0.0.6, oznaczający wszystkie rutery DR oraz DBR.
  • Ruter płonący rolę DR-a przetwarza wszystkie otrzymane wiadomości DBD. Odpowiadając na nie wiadomościami DBD wysłanymi na multicast-owy adres 224.0.0.5, zawierającymi wartości LSID struktur LSA Typu drugiego (LSA Type 2). Po ustaleniu brakujących struktur LSA, rutery wymieniają pomiędzy sobą jedynie brakujące dane za pomocą zapytań LSR oraz odpowiedzi LSU, potwierdzanych wiadomościami LSAck.
Wymiana danych LSDB po elekcji rutera pełniącego role DR-a, BDR-a
  • Status relacji sąsiedztwa względem rutera pełniącego rolę DROther oraz rutera BDR możemy zweryfikować za pomocą komendy [show ip ospf interface interfejs] bądź komendy [show ip ospf neighbor [interfejs]].
    • [show ip ospf interface interfejs] – Wyświetla wartość RID oraz adres IP rutera pełniącego rolę DR-a jak i BDR-a.
    • [show ip ospf neighbor interfejs] – Wyświetla informację o wszystkich sąsiadach podłączonych do danego interfejsu.

Periodic Flooding

  • Każda struktura LSA posiada własny licznik czasu (Age), który po naliczeniu 30 minut (1800 Sekund) powinien być zresetowany przez urządzenie rozgłaszające daną strukturę LSA. Odpowiedzialny za to ruter po stworzeniu nowej struktury resetuje jej licznik czasu oraz zwiększa jej numer sekwencyjny, rozgłaszając ją do innych urządzeń.
  • Jeżeli w przeciągu czasu „MaxAge” 1 godzina (3600 Sekund), struktura LSA nie zostanie odnowiona przez ruter ją rozgłaszający, zostanie ona usunięta z bazy LSDB, a informacja o tym zdarzeniu zostanie przekazana innym sąsiadom.
  • Aktualną wartość czasu (Age) dla danej struktury, można zweryfikować za pomocą komendy [show ip ospf database].

Pozostałe tematy związane z protokołem OSPF

Struktury LSA

OSPFv3

PDFPRINT

Robert T Kucharski

Cisco Network Engineer in GPW.

Dodaj komentarz