NetCLI

(T) Nawiązywanie relacji sąsiedztwa EIGRP”

Written by

Robert T Kucharski

in

,

Proces nawiązywania relacji sąsiedztwa

Wiadomości EIGRP wymieniane pomiędzy router-ami w procesie nawiązywania relacji sąsiedztwa
  1. Router A rozpoczyna proces nawiązywania relacji sąsiedztwa, poprzez nadanie wiadomości powitalnej Hello. Na wszystkich interfejsach sieciowych aktywnych względem konfigurowanej instancji protokołu EIGRP.
  2. Jeśli otrzymana przez router B wiadomość powitalna Hello, spełnia wymagania protokołu EIGRP względem lokalnego urządzenia. Relacja sąsiedztwa zostanie nawiązana pomiędzy routerem A a routerem B.
    1. Wymieniane pomiędzy ruterami wiadomości Hello zawierają: numer ASN konfigurowanej instancji protokołu EIGRP, wartość K-Value, wykorzystywane wartości czasów (Hello Timer, Hold Time), wersję protokołu EIGRP oraz dodatkowe informacje dotyczące  wersji systemu Cisco IOS.
  3. Router B wysyła aktualizację (Full Update) zawierającą pełną zawartość własnej tablicy topologii (Topology Table).
  4. Router A potwierdza otrzymanie aktualizacji (Update packet) za pomocą wiadomości Acknowledges.
  5. Router A wysyła aktualizację (Full Update) zawierającą pełną zawartość własnej tablicy topologii (Topology Table).
  6. Router B potwierdza otrzymanie aktualizacji (Update packet) za pomocą wiadomości Acknowledges.
  7. Urządzenia rozpoczynają proces wzajemnej wymiany wiadomości Hello, w odstępach czasowych (Hello Timer).

Warunki nawiązania relacji sąsiedztwa

  • Aby routery mogły nawiązać 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 EIGRP / OSPF

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.
W sytuacji skonfigurowania dwóch adresów IP na jednym interfejsie sieciowym (Main and Secondary IP address). Adres zawarty w otrzymanej wiadomości hello musi przynależeć do przynajmniej jednej ze skonfigurowanych sieci IP (Głównej bądź zapasowej). Jeżeli jednak na jednym z urządzeń zabraknie sieci która względem sąsiada została skonfigurowana jako sieć główna, relacja sąsiedztwa nie zostanie nawiązana. Ponieważ urządzenie te będzie nadawało wiadomości powitalne Hello, jedynie z głównego adresu IP, znajdującego się w tym przypadku w sieci innej niż sąsiednie urządzenie. Poniższy przykład prezentuje poprawną konfigurację:
* R1 1.1.1.1 255.255.255.0 (Primary IP), 11.11.11.1 255.255.255.0 (Secondary IP).
* R2  11.11.11.2 255.255.255.0 (Primary IP), 1.1.1.2 255.255.255.0 (Secondary IP).

Blokowanie procesu nawiązywania relacji sąsiedztwa

  • Kiedy komenda [network sieć dzika-maska] zostanie wydana w trybie konfiguracji protokołu EIGRP, nastąpi dopasowanie podanej w komendzie sieci, do adresów IP skonfigurowanych na wszystkich aktywnych interfejsach sieciowych, przy użyciu logiki listy (ACL). Tym samym ruter:
    • Rozpocznie systematyczne wysyłanie wiadomości powitalnych Hello, na multicast-owy adres IP 224.0.0.10.
    • Doda omawianą sieć, do tablicy topologii (Topology Table).
    • Rozpocznie rozgłaszanie informacji o danej sieci, do innych sąsiadów.
  • Zdarza się, że w sieci bezpośrednio przyległej do konfigurowanego urządzenia, nie znajduje się żaden ruter. W takim wypadku aby ograniczyć wysyłanie zbędnych wiadomości powitalnych, jednocześnie nie rezygnują z rozgłaszania danej sieci, można skorzystać z funkcji interfejsu pasywnego (Passive Interface), konfigurowanego za pomocą komendy [passive-interface interfejs] z poziomu konfiguracji protokołu EIGRP.
  • Funkcja pasywnego interfejsu (Passive Interface) blokuje proces wysyłania wiadomości powitalnych na określonym interfejsie sieciowym, jednocześnie nie blokując rozgłaszania informacji o danej sieci. Dzięki czemu interfejs nie tylko nie wysyła wiadomości powitalnych, ale również ignoruje przychodzące wiadomości Hello, czym nie dosusza do nawiązania relacji sąsiedztwa pomiędzy urządzeniami znajdującymi się w konfigurowanej sieci.

Konfiguracja statycznej relacji sąsiedztwa (Unicast Neighbor)

  • W celu zredukowania nadmiernej liczby wiadomości multicast-owych, zwiększenia poziomu bezpieczeństwa czy konfiguracji sieci NBMA (np. Frame-Relay). Istnieje możliwość nawiązania statycznej relacji sąsiedztwa za pomocą komendy [neighbor adres-IP interfejs-wyjściowy] wydanej na obydwóch urządzeniach należących do tej samej sieci, w trybie konfiguracji protokołu EIGRP.
Konfiguracja statycznej relacji sąsiedztwa, nie dodaje wskazanej w komendzie sieci, do procesu rozgłaszania protokołu EIGRP. W takiej sytuacji nadal istnieje konieczność użycia komendy [network sieć dzika-maska].
Po skonfigurowaniu statycznej relacji sąsiedztwa, system IOS automatycznie zablokuje możliwość dynamicznego nawiązania relacji sąsiedztwa na interfejsie sieciowym, do którego należy wskazany adres IP (Sąsiada).
Statycznie skonfigurowane relacje sąsiedztwa mogą zostać wyświetlane za pomocą komendy [show ip eigrp neighbors detail].

Manipulowanie wartościami czasów Hello oraz Hold Timers

  • Jedną z najważniejszych cech protokołów routingu dynamicznego, jest funkcja zbieżności (convergence), dzięki której router po utracie jednej z tras, może znaleźć inną drogę prowadzącą do tej samej sieci docelowej. Im ruter szybciej wyszuka nowe połączenie a następnie doda je do tablicy routingu, tym krótszy będzie przestój w działaniu sieci.
  • Czas zbieżności jest między innymi zależny od tego jak szybko zostanie wykryta utrata połączenia z siecią docelową. Ponieważ bez wykrycia faktu istnienia problemu nie można go naprawić. W przypadku protokołu EIGRP utrata łączności pomiędzy sąsiadami jest wykrywana za pomocą wiadomości Hello. Oczywiście przy założeniu, że interfejs łączący sąsiednie urządzenia jest w stanie up/up, w innym przypadku router od razu wykryje problem z łącznością.
  • Domyślnie wiadomości Hello są wymieniane pomiędzy sąsiadami, w odstępie czasowym 5 sekund. W przypadku nieotrzymania wiadomości Hello w przeciągu 15 sekund (Hold Timers), ruter uzna że sąsiednie urządzenie nie jest już dostępne, a tym samym usunie je z tablicy sąsiedztwa (Neighbour Table).
  • Zmniejszenie domyślnych wartości czasu Hello oraz Hold Timers może umożliwić szybsze wykrywanie problemów.
  • Domyślny czas Hello Timers – Dla sieci Ethernet wynosi 5 sekund, natomiast dla sieci NBMA wynosi 60 sekund.
  • Domyślny czas Hold Timers – Dla sieci Ethernet wynosi 15 sekund, natomiast dla sieci NBMA wynosi 180 sekund. 
Domyślnie czas Hold Timers stanowi trzykrotność wartości czasu Hello (Zachowanie takiej zależności nie jest konieczne, lecz zalecane przez Cisco).
W celu uzyskania szybszej zbieżności protokołu EIGRP, przy jednoczesnym zmniejszeniu zużycia procesora CPU, Cisco zaleca stosowanie protokołu BFD (Bi-directional Forwarding Detection). Wykorzystuje on wsparcie sprzętowe (Hardware), w celu wymiany wiadomości Keepalive, w czasie nie dłuższym niż 999 milisekund. Dzięki takiemu rozwiązaniu poszczególne wiadomości Keepalive nie muszą być przetwarzane przez procesor obydwóch urządzeń, jak ma to miejsce w przypadku domyślnej metody wykorzystującej wiadomości Hello.

Konfiguracja czasu Hello oraz Hold Timers

Pełna konfiguracja czasów protokołu eigrp została opisana w artykule: Podstawowa konfiguracja protokołu EIGRP.

  • Zmiana
    wartości czasu Hello Time oraz wartości czasu Hold Timers,jest dokonywana względem określonego interfejsu sieciowego. Należy
    przy tym pamiętać, aby wprowadzone zmiany zostały wdrożone na wszystkich
    urzadzeniach należących do tej samej sieci. Niezastosowanie się to tej zasady
    może doprowadzić do braku jednolitej wymiany wiadomości pomiędzy sąsiadami. A tym
    samym:
    • Po
      wysłaniu pierwszej wiadomości Hello wraz z nowymi ustawieniami czasów, inne urządzenia
      dostosują się do wprowadzonych zmian, prowadząc wymianę wiadomości powitalnych
      w nowo ustalonej częstotliwości. Jednak zmiana ta będzie stosowana tylko i
      wyłącznie w przypadku komunikacji sąsiednich urządzeń z urządzeniem którw
      wprowadziłoomawiane zmiany, tymczasem wymiana wiadomości pomiędzy innymi sąsiadami
      nie ulegnie zmianie.
Należy przy pamiętać, że system Cisco IOS nie chroni administratora przed wpisaniem wartości czasu Hello większej niż wartość Hold Timers, co może doprowadzić do systematycznego zrywania relacji sąsiedztwa pomiędzy routerami (Flapowania).

Nawiązywanie relacji sąsiedztwa w sieciach WAN

  • Frame Relay Neighborship – W przypadku połączenia Frame Relay relacja sąsiedztwa protokołu EIGRP zostaje nawiązana pomiędzy głównym odziałem HQ a innymi oddziałami (Spoke).
  • MPLS VPN Neighborship – W przypadku połączenia MPLS VPN relacja sąsiedztwa protokołu EIGRP zostaje nawiązana pomiędzy ruterami brzegowymi (CE – Customer Edge) a routerami dostawcy ISP (PE – Provider Edge).
  • Metro Ethernet Neighborship – W przypadku połączenia Metro Ethernet relacja sąsiedztwa protokołu EIGRP zostaje nawiązana pomiędzy wszystkimi oddziałami w topologii Full-mesh, bądź w inny sposób zależny od konfiguracji połączenia WAN (Metro Ethernet).

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

EIGRPv6

Comments

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

More posts