(T) Proces konwergencji protokołu EIGRP

Proces konwergencji EIGRP

Wstęp do procesu konwergencji protokołu EIGRP

  • Proces konwergencji protokołu EIGRP, jest w większości przypadków bardzo wydajny. Zdarzają się jednak sytuację, w których reagowanie na zachodzące w sieci zmiany trwa dłużej, zwiększając czas oczekiwania z dziesiętnych sekundy do okresu sekund. Aby zniwelować możliwość wystąpienia takiej sytuacji, administrator sieci musi odpowiednio skonfigurować ustawienia protokołu EIGRP, względem procesu wybierania trasy zapasowej (Feasible Successor).
  • Proces szybkiej konwergencji protokołu EIGRP, opiera swoje działanie na trasie następnego przeskoku (Successor route), a w szczególności na terasie zapasowej (Feasible Successor). Dzięki wykorzystaniu powyższych tras, protokół EIGRP jest w stanie szybko przełączyć się na połączenie zapasowe, po stracie łączności z ruterem pełniącym rolę Successor-a.
  • Poniższe komendy umożliwiają podgląd tras routingu zapisanych w tablicy topologii protokołu EIGRP:
    • Komenda [show ip eigrp topology] wyświetla trasy Successor oraz Feasible Successor.
    • Komenda [show ip eigrp topology all-links] wyświetla trasy Successor, Nonsuccessor oraz Feasible Successor.

FSM (Finite State Machine)

  • W okresie stabilnej pracy protokołu EIGRP, podczas której nie dochodzi do żadnych zmian w topologii sieciowej, trasy routingu zapisane w tablicy topologii znajdują się w trybie pasywnym (Passive). Jest to stan stabilny, w jakim powinna znajdować się każda sieć znajdująca się w tablicy topologii.
  • Input Event – Stan pasywny (Passive), może ulec zmianie w przypadku zajścia zdarzenia (Input Event), prowadzącego do ponownego wyliczenia metryki względem wszystkich tras routingu, zapisanych w tablicy topologii. Takowe zdarzenie wejściowe może być zapoczątkowane poprzez:
    • Zmianę metryki sieci bezpośrednio przylegającej.
    • Zmianę statusu (Up / Down), interfejsu sieciowego.
    • Odbiór wiadomości Update, Query bądź Replay.
  • Local Computation – Pierwszym krokiem następującym po zajściu zdarzenia wejściowego (Input Event), jest uruchomienie procesu „Local Computation”, wykorzystującego dane zawarte w tablicy topologii, w celu ponownej oceny sytuacji względem lokalnego routera, a tym samym wykrycia zmian dotyczących tras jak i roli jakie pełnią (Successor oraz Feasible Successor). Możliwym rezultatem przeprowadzenia tego procesu jest:
    • Zmiana statusu trasy Feasible Successor do roli Successor, w sytuacji w której obecna trasa Successor nie posiada już najniższej metryki.
    • Aktualizacja wartości Fasible Distance w przypadku, w którym wartość Computed Distance nowej trasy Successor jest mniejsza od obecnej wartości Fasible Distance.
    • Aktualizacja tablicy routingu, wpisem o nowej trasie Successor.
    • Wysłanie wiadomości Query do sąsiednich urządzeń w celu poinformowania ich o zmianach zaszłych w sieci.
W czasie trwania procesu „Local Computation”, sieć pozostaje w trybie pasywnym (Passive).
  • Diffusing Computation – Jeżeli tablica topologii nie posiada trasy Feasible Successor a jedynie trasę Nonsuccessor, jej automatyczne przeniesienie do roli Successor jest niemożliwe, bez wcześniejszego przeprowadzenia procesu „Diffusing Computation”. Proces ten blokuje zmianą obecnej trasy Successor, przenosząc wpis o danej sieci ze stanu pasywnego (Passive) do aktywnego (Active). W czasie trwania procesu „Diffusing Computation”, ruter nie może:
    • Zmieniać obecnej trasy Successor.
    • Zmieniać wartość rozgłaszanej metryki względem wskazanej trasy.
    • Zmieniać wartości Feasible Distance względem wskazanej trasy.
    • Rozpoczynać procesu „Diffusing Computation” względem innej trasy.

Mechanizm By Going Active

  • Domyślnie w przypadku utraty trasy Successor, tablica routingu zostanie przełączona na połączenie zapasowe Feasible Successor. Jednak, jeżeli dane urządzenie nie posiada żadnej trasy zapasowej Feasible Successor a jedynie trasę Nonsuccessor, musi przejść przez proces By Going Active (Diffusing Computation).

Działanie mechanizmu By Going Active (Diffusing Computation)

  1. Po zajściu zdarzenia (Input Event) uruchamiającego proces „Local Computation” -> „Diffusing Computation process”, status sieci zostanie zmieniony z pasywnej (Passive) na sieć aktywną (Active).
  2. Router rozpoczyna proces wysyłania wiadomości Query do każdego ze swoich sąsiadów, poza tym z którym została utracona łączność. W celu ustalenia nowej, wolnej od pętli trasy.
    1. Wysłana wiadomość zawiera informację o poszukiwanej sieci z nieskończoną metryką (Infinit Metric), w celu poinformowania innych urządzeń sieciowych o zmianie statusu sieci na aktywną (Active).
    2. Po wysłaniu wiadomości Query do sąsiedniego urządzenia, ruter oznacza daną relację sąsiedztwa flagą replay. Oczekując tym samym na odpowiedź.
  3. Sąsiednie urządzenie po odebraniu wiadomości Query, może wykonać następujące czynności.
    1. Jeżeli ruter nie posiada trasy do wskazanej sieci, w swojej tablicy topologii. Odpowie na otrzymane zapytanie Query wiadomością Replay, zawierającą informację o braku wskazanej sieci.
    2. Jeżeli ruter posiada trasę do wskazanej sieci, ale jej Sukcesorem nie jest urządzenie które nadesłało wiadomość Query. Odpowie na otrzymane zapytanie Query wiadomością Replay, zawierającą informację o posiadanej trasie.
    3. Jeżeli ruter posiada trasę do wskazanej sieci, jej Sukcesorem jest urządzenie które nadało wiadomość Query, ale ponad to posiada trasę Feasible Successor. Odpowie na otrzymane zapytanie Query wiadomością Replay, zawierającą informację o posiadanej trasie.
    4. Jeżeli ruter posiada trasę do wskazanej sieci, a jej Sukcesorem jest urządzenie które nadało wiadomość Query. Ruter przeniesie wskazaną sieć do trybu aktywnego (Active) jak i aktywuje własny proces „Diffusing Computation” (Jeżeli ruter nie posiada innych sąsiadów, bądź też w ramach swojego własnego procesu „Diffusing Computation” otrzyma od wszystkich odpowiedź replay, odpowie na otrzymane zapytanie Query wiadomością Replay).
  4. Proces „Diffusing Computation” zostaje zakończony, kiedy wszystkie rutery otrzymają odpowiedzi Replay od swoich sąsiadów. Jeżeli żaden z ruterów nie posiada trasy Successor / Feasible Successor do szukanej sieci, wyśle odpowiednią odpowiedź zawartą w wiadomości Replay. W następstwie czego sieć ta zostanie usunięta z tablicy topologii protokołu EIGRP.
Każda wiadomość Query oraz Replay jest wysyłana za pomocą protokołu RTP, związku z czym wymaga potwierdzenia wiadomością ACK.
Proces wymiany wiadomości Query oraz Replay można zaobserwować po aktywowaniu opcji Debug [debug eigrp fsm / debug eigrppackets query]. 
Proces By Going Active (Propagacja wiadomości Query & Replay)
Proces konwergencji „By Going Active” przeważnie trwa mniej niż 10 sekund, istnieją jednak sytuacje w których duży poziom skomplikowania topologii sieciowej czy problemy z łącznością, mogą doprowadzić do znacznego wydłużenia czasu tej operacji.

Mechanizm Stuck in Active

  • W czasie trwania procesu „By Going Active”, może dojść do zakłóceń w komunikacji pomiędzy sąsiadami. Czego efektem może być przedłużający się czas oczekiwania na odpowiedź Replay. Aby ograniczyć czas działania tego procesu, system Cisco IOS posiada czas zwany Active Timer, domyślnie wynoszący 3 minuty.
  • W pierwotnej formie procesu Stuck in Active ruter, który nie otrzymał odpowiedzi Replay na wysłane zapytanie Query, przez domyślną wartość czasu (Active Timer), zrywał relację sąsiedztwa z danym urządzeniem, ty samym usuwając go (Chwilowo) z tablicy sąsiedztwa (Neighbor Table). Co wymuszało ponowne, czasochłonne przywracanie relacji sąsiedztwa.
  • Nowsza wersja systemu Cisco IOS (12.2->), w celu uniknięcia niepotrzebnego zerwania relacji sąsiedztwa z innymi urządzeniami sieciowymi (Które przeważnie i tak nie były odpowiedzialne za problemy związane z procesem „By Going Active”). Wyśle specjalne zapytania SIA-Query (Stuck in Active Query) po upływie połowy czasu Active Timers (90 sekund). Spodziewając się przy tym odpowiedzi za pomocą wiadomości SIA-Replay (Stuck in Active Replay).
    • Jeżeli urządzenie otrzyma odpowiedź SIA-Replay, zresetuje wartość czasu Active Timers.
    • Jeżeli urządzenie nie otrzyma odpowiedzi SIA-Replay, zerwie relację sąsiedztwa po upływie reszty czasu Active Timer.
Sąsiednie urządzenie po otrzymaniu zapytania SIA-Query, natychmiast odeśle odpowiedź SIA-Replay, aby potwierdzić swoją dostępność. Pomimo braku gotowej odpowiedzi na pierwotne zapytanie Query.

Podgląd wiadomości Query

  • Wymieniane pomiędzy ruterami wiadomości Query / Replay, można zaobserwować w czasie rzeczywistym, po wydaniu komendy [debug eigrp packet query reply].
  • W przypadku rozpoczęcia procesu Stuck in Active ruter wyświetli następujące komunikaty:
    • [*Mar 1 03:41:35.887: EIGRP: Enqueueing QUERY on FastEthernet0/0 iidbQ un/rely 0/1 serno 38-38].
    • [*Mar 1 03:41:35.887: EIGRP: Enqueueing QUERY on FastEthernet0/1 iidbQ un/rely 0/1 serno 38-38].
  • Po zakończeniu procesu Stuck in Active ruter wyświetli:
    • [*Mar 1 03:44:36.495: %DUAL-3-SIA: Route 111.111.111.8/29 stuck-in-active state in IP-EIGRP(0) 100. Cleaning up].
    • [*Mar 1 03:44:36.495: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 2.4.2.4 (FastEthernet0/1) is down: stuck in active]. Oczywiście powyższe wydruki komendy Debug zależą od konfiguracji urządzenia.

Ograniczanie rozprzestrzeniania się wiadomości Query

Ograniczanie rozprzestrzeniania się wiadomości Query ( Za pomocą sieci Stub)

  • W niektórych rozwiązaniach sieciowych, część z routerów nie powinna rozgłaszać wszystkich tras, do innych urządzeń. Sytuacja taka może mieć miejsce w np. przypadku biura zdalnego, połączonego do dwóch niezależnych oddziałów głównych HQ. W takiej sytuacji trasy otrzymywane z jednego o biura głównego nie powinny być kierowane do drugiego, aby nie doszło do sytuacji w której ruch pomiędzy oddziałami głównymi (HQ), w przypadku utraty pomiędzy nimi połączenia bezpośredniego, będzie przechodzi przez mały odział zdalny.
  • Aby ograniczyć powyżej zaprezentowane zjawisko, protokół EIGRP umożliwia zastosowanie funkcji Stub Router. Blokuje ona możliwość rozgłaszania tras sieciowych otrzymanych od innych urządzeń (Domyślnie rutery Stub rozgłaszają jedynie trasy bezpośrednio przylegające do urządzenia oraz trasy zsumaryzowane).
  • Konfiguracja funkcji Stub, jest możliwa za pomocą komendy [eigrp stub] wydanej w trybie konfiguracji protokołu EIGRP.
  • Sieci Stub blokują rozprzestrzenianie się procesu „By Going Active”.

Ograniczanie rozprzestrzeniania się wiadomości Query (Za pomocą sumaryzacji)

  • W przypadku otrzymania przez router zapytania Query, o trasę do sieci docelowej która w tablicy routingu przynależy do trasy zsumaryzowanej. Router automatycznie odpowie wiadomością Replay, unikając tym samym rozpoczęcia procesu „Diffusing Computation”.

Unequal Metric Route Load Sharing (Load Balance)

  • Równomierne obciążenie (Lad Sharing / Load Balance) dla tras z nierówną metryką, oprócz podstawowej funkcjonalności umożliwiającej rozdysponowanie nadchodzącego ruchu sieciowego na większą liczbę połączeń, tras następnego przeskoku. Umożliwia uzyskanie szybszej konwergencji (Convergence), ponieważ w sytuacji utraty trasy głównej Successor, trasa zapasowa Feasible Successor jest już w użyciu.
  • Komenda [maximum-paths 1-32] zwiększa domyślną, maksymalną ilość tras równomiernego obciążenia.
  • Komenda [variance 1-128] zwielokrotnia maksymalną wartość nierówności metryki, względem tras współdzielonych.
Funkcja Load Balance dla tras z nierówną metryką jest dostępna jedynie dla protokołu EIGRP (Chwała Cisco).
Podgląd ustawień funkcji [maximum-path] oraz [variance] jet dostępny za pośrednictwem komendy [show ip protocols].
Funkcja Variance nie umożliwia prowadzenia równomiernego obciążenia dla tras „Nonsuccessor”.

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

EIGRPv6

PDFPRINT

Robert T Kucharski

Cisco Network Engineer in GPW.

Dodaj komentarz