Tag: Stub

Wstęp do procesu konwergencji protokołu EIGRP

• Proces konwergencji protokołu EIGRP, jest w większości przypadków bardzo wydajny, istnieją jednak sytuację w których reagowanie na zachodzące w sieci zmiany trwa dłużej, zwiększając czas oczekiwania z dziesiętnych sekund do okresu paru 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 o trasę następnego przeskoku Successor, a w szczególności na terasie zapasowej Feasible Successor. Dzięki wykorzystaniu powyższych ról, 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 wszystkie zapisane w bazie topologii trasy protokołu EIGRP: 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ć wykorzystująca protokół EIGRP.
• 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 protokołu EIGRP. Takowe zdarzenie wejściowe może być zapoczątkowane poprze:
  • 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, ruter nie może:
  • Zmieniać obecnej trasy Successor.
  • Zmieniać wartość rozgłaszanej metryki dla danej trasy.
  • Zmieniać wartości Feasible Distance dla danej trasy.
  • Rozpoczynać procesu „Diffusing Computation” względem innej trasy.

Mechanizm By Going Active

• Domyślnie w przypadku utraty trasy Successor, tablica routingu zostaje przełączona na połączenie zapasowe Feasible Successor. Jednak, jeżeli dany router 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 znalezienia nowej, wolnej od pętli trasy.
3. Sąsiednie urządzenie po odebraniu wiadomości Query, uruchomi własny proces Local Computation.
   1. Jeżeli sąsiednie urządzenie nigdy nie straciło trasy do szukanej przez wiadomość Query sieci, z tablicy routingu bądź też posiada wolną od pętli trasę Successor / Feasible Successor w swojej tablicy topologii, odpowie na otrzymane zapytanie Query wiadomością Replay, zawierającą informacje na temat danej trasy.
   2. Jeżeli sąsiednie urządzenie nie posiada trasy Feasible Successor a jedynie trasę Nonsuccessor, rozpocznie własny proces Diffusing Computation, wstrzymując tym samym odpowiedź na zapytanie Query otrzymane od swojego sąsiada. A co za tym idzie odraczając w czasie zakończenie jego procesu Diffusing Computation.
4. Proces Diffusing Computation zostaje zakończony, kiedy wszystkie rutery otrzymają odpowiedzi Replay od swoich sąsiadów.
5. 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 jak i Replay jest wysyłana za pomocą protokołu RTP i 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 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 występujące 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 ( Za pomocą sieci Stub)

• W przypadku niektórych topologii sieciowych, część z routerów nie powinna rozgłaszać wszystkich otrzymanych tras routingu, do innych urządzeń. Sytuacja taka może mieć miejsce w 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, 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ń z topologii EIGRP (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.

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

• Wstęp do protokołu EIGRP
• Wiadomości protokołu EIGRP
• Nawiązywanie relacji sąsiedztwa EIGRP
• Wyliczanie metryki EIGRP
• Algorytm DUAL EIGRP
• Proces konwergencji EIGRP
• Weryfikacja konfiguracji EIGRP
• Troubleshooting relacji sąsiedztwa EIGRP
• Troubleshooting brakujących tras routingu EIGRP
• Komendy Show, Debug oraz Clear EIGRP
• Podstawowa konfiguracja protokołu EIGRP
• Konfiguracja interfejsów, metryki EIGRP
• Filtrowanie protokołu EIGRP
• Sumaryzacja protokołu EIGRP
• Redystrybucja protokołu EIGRP
• Sieci stub EIGRP
• Uwierzytelnianie protokołu EIGRP
• BFD dla protokołu EIGRP
• Named EIGRP

EIGRPv6

• EIGRPv6 teoria
• EIGRPv6 troubleshooting
• EIGRPv6 konfiguracja