NetCLI

Tag: Neighborship

  • (Ts) Troubleshooting relacji sąsiedztwa EIGRP*

    (Ts) Troubleshooting relacji sąsiedztwa EIGRP*

    Troubleshooting relacji sąsiedztwa

    Interface is down

    • Interfejs sieciowy na którym znajduje się sąsiednie urządzenie, został wyłączony za pomocą komendy [shutdown].
    • Status interfejsu sieciowego można potwierdzić za pomocą komendy [show ip interface brief].

    Mismatched autonomous system numbers

    • Wartość numeru ASN konfigurowanej instancji protokołu EIGRP [router eigrp ASN], nie pasuje do konfiguracji sąsiedniego urządzenia (Wartość ASN musi być taka sama).
    • Większa część komend protokołu EIGRP wyświetla wartość ASN, jednak najlepsza jest komenda [show ip protocols].
    • W przypadku wykrycia problemu ze złą wartością ASN, komenda [debug ip eigrp packet] wyświetli następujący komunikat: [EIGRP: Sending HELLO on Gi0/0 – paklen 20 AS 100, Flags 0x0: (NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0].

    Incorrect network statement

    •  

    Mismatched K values

    • Xxx [%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 2.4.2.4 (FastEthernet0/1) is down: K-value mismatch]

    Passive interface

    Different subnets

    Authentication

    Access list

    Timers

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

    EIGRPv6

  • (T) Nawiązywanie relacji sąsiedztwa OSPF**

    (T) Nawiązywanie relacji sąsiedztwa 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 zbierające nadchodzące struktury LSA typu pierwszego, w obrębie jednej sieci wielodostęp-owej. W celu ich przetworzenia a następnie rozesłania w postaci struktury LSA typu drugiego, do sąsiednich urządzeń (W obrębie jednej sieci wielodostęp-owej).
    • BDR (Buckup Designated Router) – Ruter zapasowy , przejmujący rolę aktywną (DR) w przypadku awarii rutera DR-a.
    • DROther – Każdy ruter sieci wielodostęp-owej, nie pełniący roli DR-em bądź BDR-em.
    • Stan Adjacent – Osiągają rutery DROther w relacji z innymi urządzeniami działającym w trybie DROther (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 relacji sąsiedztwa osiągają pełny stan 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, 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 prowadzą elekcję urządzenia pełniącego rolę DR-a (Designated Router), na podstawie wymienianych pomiędzy sobą wiadomości Hello. Po zakończeniu procesu elekcji do wybranego rutera DR kierowane są wszystkie wiadomości LSA typu pierwszego , nadchodzące od sąsiadów należących do tej samej sieci wielodostęp-owej. Następnie DR odsył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.
    • Ponadto oprócz rutera DR, następuje elekcja urządzenia zapasowego BDR (Backup Designated Router), mogącego automatycznie przejąć rolę aktywną (DR) w przypadku utraty kontaktu z obecnym ruterem DR.
    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 baz LSDB).

    Elekcja rutera DR oraz BDR

    • Rolę aktywną (DR) przejmuje urządzenie z najwyższą wartością priorytetu (0–255). Jeżeli wartość ta jest taka sama na wszystkich urządzeniach, pod uwagę brana jest najwyższa wartość RID.
    • Urządzenie z drugą najwyższą wartością (Priorytetu / wartości RID) przejmuje rolę zapasową BDR (Backup Designated Router).
    • 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 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 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 żadnej wiadomości Hello).
    • Init State – Połączenie z sąsiednim ruterem zostaje przeniesione w stan „Init” zaraz po otrzymaniu pierwszej wiadomości Hello, w której lista widzianych 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 widzianych 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”, 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”:
    • Obydwa urządzenia wysyłają do siebie wiadomości powitalne Hello, na Multicast-owy adres IP (224.0.0.5, Init).
    • 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.
    • Obydwa urządzenia wysyłają kolejne wiadomości powitalne Hello, zawierające wartość RID sąsiedniego routera.
    • Po otrzymaniu wiadomości Hello zawierającej lokalną wartością RID, wpisaną w listę widzianych routerów (Seen), relacja pomiędzy urządzeniami przechodzi w stan „Two-Way State”.
    • 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” ze stanu „Init” bądź stanu „Two-Way” 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 dla struktur 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”. W tym momencie 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 dla każdej z brakujących struktur. 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”.
    stanie „Exchange State” wymianie ulegają jedynie dane LSID oraz numery sekwencyjne wszystkich struktur LSA. Natomiast 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ą adresu Multicast-owego.
    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 inicjonowanie wymiany wiadomości DBD czy określanie wartości numeru sekwencyjnego dla struktur LSA. Tmczasem 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 tymi samymi wiadomościami 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

    OSPFv3

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

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

    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

  • (K) Podstawowa konfiguracja protokołu EIGRP”

    (K) Podstawowa konfiguracja protokołu EIGRP”

    Wstęp teoretyczny do konfiguracji protokołu EIGRP

    1. Pierwszym krokiem umożliwiającym konfigurację dynamicznego protokołu routingu, jest stworzenie nowej instancji protokołu EIGRP za pomocą komendy [router eigrp ASN] wydanej w trybie konfiguracji systemu IOS. Podana wartość ASN odnosi się do systemu autonomicznego (Autonomous System Number), w którym będzie pracowała dana instancja protokołu EIGRP (W przypadku konfiguracji przełącznika warstwy trzeciej najpierw należy włączyć funkcjonalność routingu za pomocą komendy [ip routing] wydanej w trybie konfiguracji systemu IOS).
    2. Po stworzeniu nowej instancja protokołu EIGRP, należy określić jakie sieci będą przez nią rozgłaszane za pomocą komendy [network sieć dzika-maska]. Po zastosowaniu nie mniejszej komendy router rozpocznie:
      1. Wysyłanie wiadomości powitalnych na określonych przez komendę [network] interfejsach. W celu nawiązania relacji sąsiedztwa z routerami podłączonymi do tej samej sieci.
      2. Proces dodawania sieci przyległych, określonych przez komendę [network] do tablicy topologii sieciowej.
    3. Jeżeli komenda [network] nie będzie zawierała maski, router zapiszę podaną sieć jako sieć klasową (A,B bądź C). Aktywując daną instancję protokołu EIGRP na wszystkich interfejsach które należą do określonej sieci bezklasowej.
    4. Jeżeli komenda [network] zawiera maskę, router aktywuje daną instancję protokołu EIGRP na wszystkich interfejsach, które należą do określonej sieci bezklasowej. W celu określenia interfejsów spełniających dane kryterium, router posłuży się logiką listy dostępu ACL, względem adresów IP skonfigurowanych na wszystkich interfejsach urządzenia.

    Podstawowa konfiguracja protokołu EIGRP

    Rozgłaszanie sieci z poziomu konfiguracji protokołu EIGRP

    (config)# router eigrp ASN

    Przechodzi do poziomu konfiguracji protokołu EIGRP.
    Numer systemu autonomicznego (ASN) nie jest w przypadku protokołu EIGRP tak samo istotny jak ma to miejsce w protokole BGP, niemniej jednak musi być on taki sam na sąsiednich urządzeniach, aby mogły one nawiązać pomiędzy sobą relację sąsiedztwa.

    (config-router)# eigrp router-id RID(0-255.0-255.0-255.0-255)

    Statycznie definiuje wartość RID (Router ID), względem konfigurowanego rutera. 
    Jeżeli wartość RID nie została statycznie skonfigurowana, konfigurowane urządzenie wykorzysta najwyższy adres IP interfejsu Loopback lub jeżeli takowego niema, najwyższy adres IP innego interfejsu no-loopback (Np. Serialowego czy Ethernet-owego).

    (config-router)# network sieć [dzika-maska]

    Włącza propagowanie wiadomości powitalnych (Hello) na interfejsach sieciowych, których adres IP należy do sieci określonej w powyższej komendzie. W przypadku protokołu EIGRP można wykorzystywać również adresację klasową (Nie wymagającą podania maski sieciowej).

    # show ip eigrp interface [interfejs]

    Wyświetla szczegółowe informacje na temat określonego interfejsu / wszystkich interfejsów sieciowych, względem których aktywowany został protokół EIGRP.
    Niektóre komendy „network”, po zapisaniu w konfiguracji tymczasowej, mogą ulec zmianie a tym samym być widoczne pod inną postacią. Przykładowo zapis [network 10.1.1.1] zostanie zapamiętany jako adres klasowy [network 10.0.0.0].

    (config-router)# redistribute connected [metric] [router-map]

    Rozpoczyna rozgłaszanie sieci bezpośrednio przyległych do konfigurowanego urządzenia.

    (config-router)# distance eigrp 1-255(Internal) 1-255(External)

    Zmienia domyślną wartość dystansu administracyjnego (AD), względem tras wewnętrznych (Internal) oraz zewnętrznych (External).

    (config-router)# distance 1-255(AD) sieć dzika-maska

    Zmienia domyślną wartość dystansu administracyjnego (AD) względem określonej trasy routingu, należącej do wskazanej w komendzie sieci.

    # show ip protocols | section eigrp

    Wyświetla szczegółową konfigurację protokołu EIGRP, w tym ustawienia dystansu administracyjnego (AD).

    Konfiguracja dodatkowych ustawień protokołu EIGRP

    Manipulowanie domyślnymi wartościami czasów

    Teoria związana z czasami protokołu EIGRP została opisana w artykule: Wiadomości protokołu EIGRP oraz Nawiązywanie relacji sąsiedztwa.

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip hello-interval eigrp ASN 1-65535(5/60)

    Zmienia domyślną wartość czasu „hello-interval”.

    (config-if)# ip hold-time eigrp ASN 1-65535(15/180)

    Zmienia domyślną, rozgłaszaną wartość czasu „hold-time”. Komenda ta nie wpływa na ustawienia konfigurowanego urządzenia sieciowego a jedynie na sąsiedni ruter (Zgodnie z zaleceniami Cisco wartość „hold-time” powinna stanowić trzykrotność czasu „hello-interval”).

    (config-if)# router eigrp ASN

    Przechodzi do poziomu konfiguracji protokołu EIGRP.

    (config-router)# timers active-timer {1-65535(minuty)(3) / disabled}

    Modyfikuje domyślną wartość czasu „active-timer”, bądź ją dezaktywuje (Disabled).
    Wartość „active-timer” określa ile czasu ruter będzie czekał na odpowiedź wiadomości Query, zanim przejdzie w stan SIA (Stuck in Active).

    (config-router)# timers graceful-restart purge-time 20-300(sekundy)(240)

    Zmienia domyślną wartość czasu „graceful-restart purge-time”.

    # show ip eigrp [ASN] interfaces detail [interfejs]

    Wyświetla konfigurację czasu „hello-interval” oraz „hold-time”, względem określonego interfejsu bądź wszystkich interfejsów sieciowych, aktywnych względem protokołu EIGRP.

    # show ip protocols | section eigrp

    Wyświetla szczegółową konfigurację protokołu EIGRP, w tym ustawienia czasu „active-timer”.

    Konfiguracja funkcji Load-balance

    (config)# router eigrp ASN

    Przechodzi do poziomu konfiguracji protokołu EIGRP.

    (config-router)# maximum-paths 1-32

    Określa maksymalną ilość połączeń działających w trybie równoważnego obciążenia, dla wielu tras o tej samej bądź różnej metryce. W przypadku tras posiadających różne wartości metryki, konieczne jest zastosowanie dodatkowej komendy [variance].

    (config-router)# variance 1-128(1)

    Przepuszcza ruch równoważony pomiędzy dwoma trasami o różnych wartościach metryki.
    Przykładowo, jeżeli ruter posiada dwie trasy o metrykach równych 100 i 300, a wartość „Variance” będzie wynosiła 3. To urządzenie te nie dopuści do zastosowania równoważonego obciążenia ruchu sieciowego. Ponieważ 3*100 = 300, natomiast zgodnie z powyższym przykładem wartość ta musi wynosić co najmniej 301, związku z tym wartość “Variance” powinna posiadać wartość równą co najmniej 4.

    # show ip protocols | section eigrp

    Wyświetla szczegółową konfigurację protokołu EIGRP, w tym ustawienia związane z funkcją „maximum-paths” oraz funkcją „variance”. 
    Każda trasa, której metryka jest mniejsza od wartości FD pomnożonej przez wartość „Variance”,będzie wykorzystywana przy równoważonym obciążeniu.

    Aktywacja / dezaktywacja procesu EIGRP

    (config)# router eigrp ASN

    Przechodzi do poziomu konfiguracji protokołu EIGRP.

    (config-router)# [no] shutdown

    Włącza / Włącza określony proces protokołu EIGRP, powodując: 
    * Usunięcie wszystkich relacji sąsiedztwa.
    * Wstrzymanie procesu nawiązywania nowych relacji sąsiedztwa.
    * Zatrzymanie procesu rozgłaszania wiadomości powitalnych (Hello). 
    Dezaktywowanie procesu EIGRP, nie usuwa bieżącej konfiguracji z systemu IOS.

    Konfiguracja statycznej relacji sąsiedztwa

    (config)# router eigrp ASN

    Przechodzi do poziomu konfiguracji protokołu EIGRP.

    (config-router)# neighbor adres-IP interfejs-wychodzący

    Rozpoczyna proces nawiązywania statycznej relacji sąsiedztwa, z ruterem wskazanym w komendzie.

    Konfiguracja funkcji split-horizon

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# [no] ip split-horizon eigrp ASN

    Wyłącza / Włącza funkcję split-horizon na konfigurowanym interfejsie sieciowym.

    Konfiguracja maksymalnego obciążenia

    (config)# router eigrp ASN

    Przechodzi do poziomu konfiguracji protokołu EIGRP.

    (config-if)# ip bandwidth-precent eigrp ASN 1-999999(%)(50)

    Ogranicza wykorzystanie pasma sieciowego przez protokół EIGRP. Zdefiniowana w komendzie wartość, określą jaki procent pasma może być wykorzystywany na potrzeby protokołu EIGRP (Wiadomości aktualizacyjne, powitalne jak i wszelkie inne wiadomości).

    Pozostałe tematy związane z konfiguracją protokołu EIGRP

    EIGRPv6