W artykule poruszę konfigurację protokołu EIGRP, która będzie przeprowadzana na konkretnych przykładowych topologiach sieci. Zakres materiału obejmuje zagadnienia omawiane na kursie CCNA oraz CCNP. A mówiąc trochę bardziej szczegółowo zajmiemy się m.in. uruchomieniem protokołu, metryką, uwierzytelnieniem, redystrybucją tras oraz ich filtrowaniem ale zanim przejdziemy do omawiania tych zagadnień – podstawy.

A więc jak to ktoś kiedyś śpiewał – „już nie czekamy, zaczynamy”

Na rysunku powyżej, krótkie podsumowanie dostępnych protokołów. Tak by sobie uzmysłowić jak protokół EIGRP jest klasyfikowany.

Szukając informacji na temat protokołu EIGRP w literaturze natkniemy się często na określenie, że jest to protokół hybrydowy czyli taki, który zajmuje miejsce pomiędzy tradycyjnymi protokołami wektora odległości (np. RIP) a protokołami łącze-stan (np. OSPF). Jest to nieprawda ponieważ protokół EIGRP jest klasyfikowany jako protokół wektora odległości. Nieporozumienie to wynikło z pewnych cech działania samego protokołu EIGRP, które to cechy bliższe są protokołom łącze-stan.

Przyjrzyjmy się zatem jakimi funkcjami dysponuje protokół EIGRP i co go odróżnia od tradycyjnych protokołów distance vector.

Jak widać po zamieszczonych różnicach w sposobie działania protokołów, protokół EIGRP bazuje na tradycjach protokołów wektora odległości ale ma swoje własne mechanizmy, które czynią ten protokół stabilniejszym w działaniu, pewnym i po prostu szybszym.

W naszych rozważaniach na temat tego protokołu często będzie pojawiało się pojęcie algorytmu DUAL (zresztą już temat ten został zasygnalizowany) więc wypada napisać parę słów wyjaśnienia. Jeśli czytałeś moje wcześniejsze wpisy (np. o protokołach routingu dynamicznego) to Czytelniku powinieneś wiedzieć, że tradycyjne protokoły routingu wektora odległości, po upływie czasu ważności usuwają wpisy tras do sieci zdalnych ze swoich tablic routingu. By wpisy te mogły znajdować się w tablicy routingu routera co pewien, ustalony czas urządzenie musi otrzymać aktualizację okresową. Protokół EIGRP wraz z algorytmem DUAL (silnik tego protokołu) całkowicie rezygnuje z tego rozwiązania wprowadzając nowe podejście a mianowicie implementuje mechanizm monitorowania stanu relacji z swoimi sąsiadami (za pomocą tzw. lekkiego protokołu hello) i wprowadza nowy typ aktualizacji wyzwalanych. Aktualizacje te zostały tak nazwane gdyż wysyłane są tylko w sytuacji pojawienia się nowego łącza lub awarii już istniejącego. Takie podejście do sprawy ma jeden zasadniczy cel a mianowicie zmniejszenie zużycia zasobów routera (procesor), gdyż każdorazowe uruchomienie algorytmu DUAL (proces wyliczenia najlepszych tras) mocno obciąża procesor urządzenia. Dlatego by zniwelować to niekorzystne zjawisko lecz także uzyskać szybszą zbieżność sieci oprócz tradycyjnej tablicy routingu została wprowadzona dodatkowa tablica tras zapasowych. W tablicy tej znajdują się trasy do sieci docelowych (trasy z gorszą metryką niż ta znajdująca się w tablicy routingu), które zapewniają nam alternatywną drogę dotarcia do danej sieci. Przy czym algorytm DUAL musi te trasy uznać jako wolne od pętli (ang. loop-free). Trasa wolna od pętli to taka trasa, która prowadzi do sieci docelowej nie przez rozważany router. Może trochę brzmi to niejasno lecz poniższe rysunki rozwieją wątpliwości.

Przypuśćmy, że mamy topologię jak na rysunku poniżej a nasze rozważania będziemy prowadzić z punktu widzenia routera R3. Naszym celem jest skomunikowanie się z siecią 192.168.1.0/24. By osiągnąć cel router R3 wybierze trasę prowadząco do routera R2 a następnie do routera R1. Zadajmy pytanie - Czy istnieje zapasowa trasa i czy ewentualna trasa zapasowa może prowadzić przez router R4?

Odpowiedź - NIE. Ponieważ rozważana trasa prowadzi przeze mnie (pętla). R4 zna trasę do sieci zdalnej 192.168.1.0/24 dzięki mnie. Tak więc nie istnieje żadna alternatywna droga do sieci 192.168.1.0/24

Zmodyfikujmy trochę naszą topologię i dodajmy połączenie pomiędzy routerem R4 a routerem R2 i spróbujmy znów sobie odpowiedzieć na postawione pytanie.

Odpowiedź - TAK. Teraz router R4 posiada trasę alternatywną (bez pętli) do sieci 192.168.1.0/24 (trasa utworzona dzięki połączeniu routera R4 z routerem R2).

Przedstawiony przeze mnie opis (a raczej słowo wstępu i ogólny zarys) algorytmu DUAL nie wyczerpuje tematu gdyż dociekliwy czytelnik mógłby zapytać - Skąd router R3 wie o tej nowej alternatywnej drodze dotarcia do sieci 192.168.1.0/24? Lecz by posunąć się dalej należy w pierwszej kolejności omówić typy pakietów wykorzystywanych przez proces EIGRP i typie przesyłanych informacji. Więc pozwól Czytelniku, że na razie na tym się zatrzymamy by za chwilę do tematu powrócić.

Protokół EIGRP celem nawiązania relacji z sąsiadami lecz także przy wymianie niezbędnych pakietów używa protokołu RTP (ang. Reliable Transport Protocol). Protokół ten został tak zaprojektowany by działał niezależnie od warstwy sieci. Wymóg ten został wprowadzony ponieważ EIGRP może prowadzić routing w sieciach opartych o IPX czy AppleTalk (notabene sieci bazujące o te rozwiązania są już rzadko stosowane, ponieważ zostały wyparte przez protokół IP) a w sieciach tych nie używa się zestawu protokołów TCP/IP. Routing różnych protokołów jest realizowany za pomocą tzw. modułów PDM (ang. Protocol Dependent Modules), moduły te odpowiadają za routing każdego z wymienionych protokołów warstwy sieciowej.

Cechy protokołu RTP przedstawiono poniżej:

• • • zapewnia dostarczanie i odbiór pakietów EIGRP,
    • nie korzysta ze stosu TCP/IP (protokół TCP oraz UDP),
    • umożliwia wiarygodne (ang. reliable) dostarczanie - tak jak TCP,
    • umożliwia dostarczanie bez potwierdzania (ang. unreliable) – tak jak UDP.

Poniżej na rysunku ogólny schemat pakietu EIGRP.

Część danych protokołu EIGRP jest enkapsulowana w polu TLV (ang. Type/Length/Value) a pole te następnie opatrzone jest nagłówkiem pakietu EIGRP. Najczęściej do czynienia będziemy mieć z pakietami TTV typu: 0x0001 - parametry EIGRP; 0x0102 - wewnętrzne trasy IP oraz 0x0103 - zewnętrzne trasy IP.

Następnie te wszystkie informacje łączone są w pakiecie IP. Adresem IP źródłowym jest adres interfejsu wysyłającego pakiet a adresem docelowym jest adres grupowy 224.0.0.10. Pole protokołu zostaje ustawione na 88. W przypadku enkapsulacji pakietu IP w ramce ethernetowej źródłowym adresem MAC jest adres interfejsu wysyłającego natomiast adresem docelowym jest również adres grupowy - 01-00-5E-00-00-0A.

Protokół EIGRP potrafi również wysyłać pakiety jednostkowe. Sytuacja ta zachodzi gdy korzystamy z polecenia: neighbor <adres_IP_sąsiedniego_routera> <interfejs_lokalny> Polecenie to nakazuje utworzenie tzw. statycznej relacji sąsiedzkiej (omówione w dalszej części). Komunikaty jednostkowe są również wykorzystywane w niektórych połączeniach typu punkt-punkt.

W nagłówku pakietu EIGRP możemy znaleźć następujące informacje:

W nagłówku pakietu EIGRP pola na które należy zwrócić szczególną uwagę to pole:

• • • kod operacyjny - pole to definiuje jeden z typów pakietu EIGRP: Hello, aktualizacja, zapytanie i odpowiedź,
    • numer systemu autonomicznego - pole określa instancję protokołu EIGRP (na routerze może być włączonych wiele niezależnie od siebie procesów EIGRP).

W przypadku wysyłania pakietu zawierającego parametry EIGRP pakiet będzie wyglądał następująco:

Informacje zawarte w tym pakiecie są szczególnie ważne z punktu prowadzenia całego procesu EIGRP, gdyż dane te są używane m.in. do obliczenia metryki (wagi metryki - wartości od K1 do K5). Domyślnie (co nie raz jeszcze zostanie powtórzone) tylko pole K1 (szerokość pasma) i K3 (opóźnienie) jest ustawione na 1 natomiast pozostałe pola przyjmują wartość 0.

W polu czas wstrzymania (ang. hold time) została umieszczona wartość czasu po jakim router uznaje sąsiada (wysyłającego pakiet) za nieczynnego.

W przypadku gdy pakiet niesie informację o wewnętrznych trasach EIGRP jego postać jest następująca:

Pola krytyczne to:

• • • miejsce przeznaczenia - pole zawiera informację o adresie sieci docelowej. Pole te zawiera wyłącznie część sieciową adresu np. gdy sieć docelowa to 172.16.0.0/16 umieszczana jest informacja 172.16. Gdy część sieciowa przekracza maksymalny rozmiar pola (24 bity) np. przy sieci 10.0.0.0/30 pole to jest rozszerzane o kolejne 32 bity, niewykorzystane miejsce jest uzupełniane 0.
    • opóźnienie - czyli całkowita suma opóźnień od źródła do miejsca przeznaczenia. Opóźnienie jest wyrażane w 10 mikrosekund,
    • szerokość pasma - czyli najniższa skonfigurowana wartość interfejsu na trasie,
    • długość prefiksu - maska podsieci wyrażona prefiksem np. dla maski 255.255.255.252 będzie umieszczona wartość 30.

Gdy w ogłoszeniu EIGRP jest zawarty komunikat o trasie zewnętrznej, pakiet zostaje wzbogacony o dodatkowe pola.

Trasy zewnętrze to takie trasy, które zostały uzyskane od innych protokołów routingu, trasy statyczne o których informacja jest przekazywana poprzez protokół EIGRP, trasy sumaryczne a także trasa domyślna 0.0.0.0 0.0.0.0

Protokół EIGRP korzysta z pięciu różnych pakietów przy czym niektóre z nich zawsze występują parami.

Pierwszy typ pakietu to pakiet Hello. Pakiety te służą do:

• • • odkrywania sąsiadów,
    • nawiązywania sąsiedztwa,
    • podtrzymywania sąsiedztwa.

Pakiety te wysyłane są zaraz po skonfigurowaniu protokołu EIGRP na danym interfejsie. Ich głównym zadaniem jest wykrycie sąsiadów (innych routerów realizujących proces EIGRP) a także są niezbędne aby routery pomiędzy sobą utworzyły przyległość. Podtrzymanie sąsiedztwa z danym routerem trwa tak długo jak są od niego otrzymywane pakiety Hello. Dla routera oznacza to, że sąsiad jest osiągalny a co za tym idzie trasy do sieci zdalnych otrzymywane od niego są również dostępne. Podczas transmisji pakietów Hello jest wykorzystywany multicast (komunikacja grupowa) a także pakiet ten nie wymaga potwierdzenia (tzw. komunikacja zawodna - router ogłaszający nie ma pojęcia czy odbiorca pakiet otrzymał).

Domyślnie w sieciach Ethernet pakiety te są rozsyłane co 5 sekund a czas wstrzymania (uznanie routera za nie osiągalnego) wynosi trzykrotność czasu rozsyłania czyli 15 sekund. Po tym czasie gdy router nie odbierze od sąsiada pakietu Hello, zrywa relację sąsiedzką a trasy uzyskane od sąsiada uważa za nieosiągalne (no chyba, że istnieją trasy alternatywne). W sieciach typu Frame Relay, ATM (łącze o przepustowości 1544 Mb/s lub mniej) czas rozsyłania pakietów Hello wydłuża się do 60 sekund, natomiast czas wstrzymania, analogicznie jak w przypadku sieci ethernetowych jest trzykrotnością czasu rozsyłania czyli wynosi 180 sekund.

Liczniki te oczywiście można zmieniać (pokażę to w dalszej części wpisu) ale co ważne do utworzenia relacji sąsiedzkiej np. pomiędzy dwoma routerami nie jest wymagana zgodność tych parametrów co oznacza, że na jednym z routerów mogą zostać wykorzystane wartości domyślne (rozsyłanie co 5s, czas wstrzymania 15s) a na drugim czasy te mogą być ustawione w inny, odmienny sposób (np. rozsyłanie co 3s, czas wstrzymania 9s). Oczywiście, rzadko się zdarza by administrator sieci, taką konfigurację przeprowadził, zazwyczaj na wszystkich routerach czasy są ustawiane jednakowo a stosunek czasów 3:1 (choć wcale taki być nie musi) wydaje się podejściem wyważonym.

Ważnym aspektem mającym wpływ na utworzenie relacji sąsiedzkiej są wagi metryki (wykorzystywane do obliczenia kosztu dotarcia do sieci), które to zawarte są w pakiecie Hello. Tu już musi wystąpić pełna zgodność gdyż niedopasowanie tych informacji uniemożliwi utworzenie przyległości z sąsiadem.

Innym parametrem w którym musi nastąpić zgodność a zawartym również w pakiecie Hello jest numer systemu autonomicznego. Tak naprawdę numer ten powinien być przyznany przez niezależną organizację jaką jest urząd IANA a także podległe mu jednostki (lokalny RIR) to w praktyce numer ten jest tożsamy z numerem procesu (i aby uniknąć niedomówień w całym artykule numer ten będę nazywał numerem procesu) i administrator sam decyduje o jego nadaniu (wartość od 1 do 65535). Dla nas najważniejszy jest fakt, iż numer ten musi zostać użyty na wszystkich routerach biorących udział w procesie EIGRP (odmiennie niż w OSPF) .

Pakiety Update (aktualizacje):

• • • zawierają tylko niezbędne informacje (np. o zmianie, która wystąpiła),
    • wysyłane są tylko do tych routerów, które potrzebują tej informacji,
    • wykorzystują transmisję RTP z potwierdzaniem

W przeciwieństwie do opisywanego już protokołu RIP, aktualizacje w protokole EIGRP przyjmują charakter okresowy oznacza to, że wysłanie aktualizacji zachodzi tylko wtedy gdy istnieje taka potrzeba (brak okresowości ich wysyłania). Jak już jesteśmy w temacie aktualizacji to trzeba zaznaczyć, że oprócz aktualizacji okresowych w protokole EIGRP będzie jeszcze mowa o tzw. aktualizacjach częściowych (ang. partial) oraz ograniczonych (ang. bounded). Aktualizacja częściowa to taka aktualizacja, która zawiera jedynie informację o zaistniałej zmianie - dotyczy konkretnej trasy (np. zmiana metryki). Natomiast o aktualizacji ograniczonej będziemy mówili wtedy, gdy trafia ona tylko do tych routerów, których ta zmiana dotyczy.

Gdy relacja sąsiedzka z routerem zostaje nawiązana, tworzące je routery wymieniają się wszystkimi posiadanymi informacjami o topologii sieci. Gdy wymiana ta zostaje zakończona, ponowna aktualizacja jest wysyłana tylko wtedy gdy w sieci wystąpi zmiana. Poprzez zmianę rozumiemy np. pojawienie się nowego sąsiada a co za tym idzie nowych tras bądź tras alternatywnych do już istniejących sieci; zmiana składowych metryk; awaria bądź odzyskanie łącza. W przypadku zaistnienia pierwszej z sytuacji (pojawienie się nowego sąsiada, bądź powrocie routera, który przez pewien czas był nieobecny) następuje aktualizacja pełna.

Tak jak w przypadku np. protokołu RIP należy mieć na uwadze, że w protokole EIGRP obowiązuje również zasada podzielonego horyzontu (ang. split horizon), która domyślnie jest włączona. Oznacza to, że router w swoich aktualizacjach nie wyśle informacji o danej sieci poprzez interfejs przez który o tej sieci się dowiedział. Oznacza to nic innego, że gdy np. router R1 poprzez interfejs s1/1/1.1 dowie się o sieci 192.168.0.0/24 to w swych aktualizacjach wysyłanych poprzez ten interfejs sieci tej nie będzie uwzględniał. Problem ten szczególnie dotyczy sieci opartych o Frame Relay gdzie domyślnie włączona reguła podzielonego horyzontu może skutecznie uniemożliwić rozpropagowanie informacji o dostępnych trasach. Na szczęście regułę tą można wyłączyć, a wyłączamy ją za pomocą polecenia: no ip split-horizon eigrp <numer_procesu> wydanym w trybie konfiguracji konkretnego interfejsu.

Pakiety niosące ze sobą informację o aktualizacji są wysyłane niezawodnie oznacza to, że router po odebraniu takiego pakietu musi fakt ten potwierdzić poprzez wysłanie pakietu potwierdzenia (ACK). Pakiety aktualizacji w sieciach wielodostępowych są rozsyłane na adres grupowy 224.0.0.10 (potwierdzenie jest wymagane od każdego sąsiada) natomiast w sieciach punkt-punkt pakiet ten jest wysyłany jako jednostkowy.

Proces wysłania aktualizacji został przedstawiony na rysunku powyżej. Sieć za routerem R1 ulega awarii i router ten natychmiast o tym fakcie powiadamia swoich sąsiadów. Zostaje wysłana aktualizacja wyzwalana (bo nastąpiła zmiana), jednocześnie jest to aktualizacja częściowa (odnosząca się do konkretnego adresu sieci), poniekąd aktualizacja ograniczona (routery, których ta zmiana dotyczy) i aktualizacja jednostkowa (gdyż routery są połączone interfejsami serialowymi (punkt-punkt).

Pakiety Acknowledgement (potwierdzenia) są wysyłane jako odpowiedź na transmisję RTP z potwierdzaniem (update, query i reply), dodatkowo są wysyłane zawodnie (nie wymagają potwierdzania) i są komunikatami jednostkowymi. Na rysunku powyżej widać, że gdy router R1 utracił łączność z siecią, po poinformowaniu o tym fakcie swoich sąsiadów, sąsiedzi ci tą informację potwierdzili.

Pakiety Query (zapytania) są używane do wyszukiwania (lecz nie tylko) sieci. Wysyłane są jako komunikaty grupowe bądź jednostkowe. Router R1 tracąc łączność z siecią (pomimo tego, że jest to sieć z którą jest bezpośrednio podłączony) rozpoczyna proces odpytywania sąsiadów czy nie jest im może znana trasa alternatywna. Pakiet Query wymaga potwierdzenia.

Pakiety Reply (odpowiedzi) są wysyłane w odpowiedzi na pakiety Query. Pakiet ten musi odesłać każdy sąsiad niezależnie od tego, czy router zna trasę do nieczynnej sieci czy nie.

Odpowiedzi są dostarczane w sposób niezawodny, tak wiec i one wymagają potwierdzenia. Tak więc każdy pakiet typu Query, Update, Reply jest potwierdzany natomiast pakiety typu Hello oraz Ack nie są potwierdzane.

Tak więc cały proces komunikacji EIGRP odbywa się według schematu poniżej.

To jeszcze by podsumować temat pakietów przyjrzyjmy się jak wymiana komunikatów odbywa się pomiędzy fizycznymi urządzeniami. Nasze rozważania przeprowadzimy na takiej oto prostej topologii.

Protokół routingu dynamicznego EIGRP pomiędzy routerami R1 a R2 został skonfigurowany (jak to zrobić przedstawię za chwilę) i komunikacja pomiędzy hostem PC1 i PC2 została ustanowiona.

Tak więc na pierwszy rzut pakiet Hello.

Po przechwyceniu pakietu Hello możemy przejrzeć jakie informacje są przekazywane sąsiadom:

1 - pakiet Hello wysyłany na adres grupowy 224.0.0.10,

2 - typ pakietu 5 czyli Hello,

3 - numer procesu EIGRP,

4 - stałe K1, K2, K3, K4, K5 wykorzystywane w procesie obliczania metryki,

5 - licznik hold-time, czas po upływie, którego zostaje zerwana relacja sąsiedzka.

Po wymianie pakietów Hello czas by routery wymieniły się miedzy sobą posiadanymi informacjami. Na routerze protokół EIGRP został wyłączony a następnie włączony ponownie. Routery wymieniły się pakietami z informacja o posiadanych trasach w tym przypadku był to pakiet Update typ 0x0002 niosący informację o trasach wewnętrznych. Poniżej przedstawiony przechwycony pakiet, który został wysłany od routera R1 (IP 192.168.0.1/30) do routera R2 (IP 192.168.0.2/30).

1 - aktualizacja jednostkowa, ponieważ łącze pomiędzy routerami to punkt-punkt (łącze serialowe),

2 - typ pakietu, (1) oznacza aktualizacje,

3 - numer procesu EIGRP,

4 - Typ TLV - 0x0002 IP Internal Routers TLV,

5 - adres następnego skoku,

6 - wartość opóźnienia,

7 - szerokość pasma,

8 - MTU,

9 - licznik skoków,

10 - wartość niezawodności,

11 - wartość obciążenia,

12 - długość prefiksu oraz miejsce przeznaczenia.

Router R2 po odebraniu aktualizacji odsyła pakiet potwierdzenia.

Aby wymusić wysłanie pakietu zapytania na routerze R1 został wyłączony interfejs łączący go z siecią 10.0.0.0/24. Router R1 stracił możliwość komunikacji z tą siecią dlatego odpytuje swoich sąsiadów czy nie znają drogi do sieci z którą kontakt został utracony. Pole Delay w adresie szukanej sieci 10.0.0.0/24 zostaje ustawione na wartość maksymalną 4294967295

Ponieważ został wysłany pakiet zapytania router R2 musi potwierdzić fakt jego otrzymania.

Router R2 na zapytanie od routera R1 wysyła odpowiedź - pakiet Replay. Ponieważ router R2 nie zna drogi do sieci 10.0.0.2 w pakiecie tym pole Delay odnośnie szukanej sieci zostaje ustawione na maksymalną wartość.

Router R1 po odebraniu pakietu Replay (dostarczany niezawodnie) musi go potwierdzić, zostaje wysłany pakiet Ack.

W konsekwencji router R1 nie znajduje alternatywnej drogi do poszukiwanej sieci bo w przyjętej topologii takiej trasy nie ma. Do analizy pakietów przesyłanych do routerów jeszcze wrócimy gdy będziemy omawiać bardziej złożoną konfigurację.

Myślę, że po tym wstępie teoretycznym (choć jeszcze zostało parę kwestii do omówienia) czas by przejść do części praktycznej. Topologia naszej ćwiczebnej sieci będzie wyglądała jak na rysunku poniżej.

Wszystkie adresy IP na routerach zostały skonfigurowane.

Aby włączyć proces routingu EIGRP na routerze w trybie konfiguracji globalnej należy wydać polecenie: router eigrp <numer_procesu> Należy pamiętać, że wybrany numer trzeba konsekwentnie używać na każdym kolejnym routerze, gdyż w przeciwnym przypadku nie zostanie ustanowiona relacja sąsiedzka i routery nie będą mogły wymienić się tablicami routingu.

Po wydaniu polecenia włączającego protokół, za pomocą komendy: network <adres_sieci> <maska> (tak samo jak w przypadku RIP i OSPF) należy określić interfejsy na których protokół EIGRP ma być uruchomiony co jest jednoznaczne z ogłaszaniem sieci do której ten interfejs należy. Po określeniu adresu rozgłaszanej sieci, router na zdefiniowanym interfejsie próbuje wykryć sąsiadów, zaczyna wysyłać pakiety Hello.

W poleceniu network w celu określenia maski sieci należy użyć maski blankietowej (ang. wildcard mask). Sposób przejścia z zapisu maski standardowej na maskę blankietową opisałem w artykule dotyczącym konfiguracji protokołu OSPF. Warto również nadmienić, że w poleceniu network można pominąć adres maski. W takim przypadku polecenie te włączy protokół routingu na wszystkich interfejsach należących do danej klasy adresowej. Maska sieci zostaje dobrana na podstawie przynależności adresu IP do danej klasy adresowej.

Konfiguracja routera najczęściej sprowadza się do wydania polecenia network w połączeniu z adresami sieci bezpośrednio podłączonych do routera. Na routerze R1 zostały rozgłoszone wszystkie sieci z którymi router jest połączony bezpośrednio (sieci: 172.16.0.0/24, 192.168.0.0/30 oraz 192.168.2.0/30).

Po skonfigurowaniu routera R1 przechodzimy do konfiguracji routera R2. Włączenie protokołu EIGRP następuje za pomocą takiego samego polecenia jak na routerze R1: router eigrp 1 Zostają zdefiniowane sieci bezpośrednio podłączone z routerem R2. Po wydaniu polecenia: network 192.168.0.0 0.0.0.3 zostaje ustanowione sąsiedztwo z routerem R1 (komunikat konsoli: Neighbor 192.168.0.1 (Serial0/1) is up: new adjacency) . Sąsiedztwo zostało nawiązane ponieważ sieć 192.168.0.0/30 jest już rozgłaszana przez router R1

Po wprowadzeniu wszystkich poleceń na routerze R2 nie pozostaje nam nic innego jak skonfigurować router R3. W trakcie wprowadzania poleceń jesteśmy informowani o nowo tworzonych relacjach sąsiedzkich z routerami R2 oraz R1.

Tak więc routery zostały skonfigurowane, nic nie stoi na przeszkodzie by sprawdzić czy nasza testowa sieć osiągnęła zbieżność czyli czy możliwa jest komunikacja z wszystkimi urządzeniami. Sprawdźmy to.

Wysyłamy ping z komputera WindowsXP_1 do WindowsXP_2 oraz WindowsXP_3

I już po tym pierwszym, prostym teście można stwierdzić - Że coś jest nie tak, gdyż niemożliwa jest komunikacja z hostem WindowsXP_3 (IP 172.16.1.10)

Sprawdźmy jak sytuacja wygląda na komputerze WindowsXP_2.

I tu sytuacja się powtarza, pierwszy test ping do komputera WindowsXP_1 zakończył się sukcesem natomiast już do WindowsXP_3 Nasuwają się pytania - Czyżby host WindowsXP_3 nie był włączony? A może host ma przypisany błędny adres IP? Czy adres bramy został poprawnie przypisany?

By potwierdzić nasze przypuszczenia przejdźmy na host WindowsXP_3 i spróbujmy stwierdzić czy rzeczywiście wina w braku komunikacji tkwi po jego stronie.

Po analizie wydanych poleceń dochodzimy do wniosku, że adres IP komputerowi WindowsXP_3 został przypisany poprawnie - IP 172.16.1.10 i tak samo adres bramy nie budzi zastrzeżeń lecz próba komunikacji z hostem WindowsXP_1 oraz WindowsXP_2 została zakończona niepowodzenie.

Może karta sieciowa uszkodzona, a może problem z okablowaniem? By wykluczyć te hipotezy spróbujmy wykonać ping w połączeniu z innymi adresami IP. Sprawdźmy komunikację z adresem IP, który jest najbliżej hosta WindowsXP_3 a mianowicie bramą i np. adresem 10.0.0.1, który został przypisany interfejsowi f0/0 routera R2

I tu dopiero mamy zagadkę, oby dwa testy zakończyły się sukcesem zarówno brama jaki i interfejs f0/0 routera R2 na nasze zapytania odpowiedziały poprawnie. Dlaczego więc nie mogę skomunikować się z hostem WindowsXP_3 (IP 10.0.0.10) choć znajduje się w tej samej przestrzeni adresowej co interfejs f0/0 routera R2? Wszystkie nasze wcześniejsze przypuszczenia okazały się nie trafne. Gdy już wiemy, że problem nie tkwi w konfiguracji hostów, nie jest spowodowany uszkodzeniem karty sieciowej czy okablowaniem nie pozostaje nam nic innego jak rozwiązania szukać w konfiguracji routerów i protokołu EIGRP. Spróbujmy zatem przeprowadzić próbę komunikacji z hostem WindowsXP_3 od drugiej strony czyli pakiety ICMP będą wysyłane z routera. Pod lupę weźmy router R2.

Z routera R2 komunikat ICPM został wysłany z wykorzystaniem wszystkich trzech interfejsów (polecenie: ping <adres_IP> source <interfejs>) pod dwa adresy IP a mianowicie 172.16.1.10 (host WindowsXP_3) oraz 172.16.0.10 (host WindowsXP_1) jak widać powyżej z adresem 172.16.0.10 nie ma problemów natomiast w przypadku adresu 172.16.1.10 tylko jeden interfejs zapewnia komunikację a mianowicie interfejs f0/0.

By rozwiązać nasz problem musimy zajrzeć do tablic routingu routerów i przekonać się jakie trasy do tych tablic zostały wpisane.

Po przyjrzeniu się informacjom jakie znalazły się w tablicy routingu poszczególnych routerów (znak D przed trasą oznacza, że została ona poznana dzięki protokołowi EIGRP, natomiast znak C to trasy podłączone bezpośrednio) można zauważyć (czytaj powinno nas zainteresować):

• • • w żadnej tablicy routingu nie odnajdujemy trasy prowadzącej do sieci 172.16.1.0./24 (poza R3 gdzie sieć ta jest do routera podłączona bezpośrednio),
    • inne maski sieci niż te które konfigurowaliśmy z użyciem polecenia network - np. router R1 ma trasę do sieci 10.0.0.0/8 a przecież na routerze R2 wydawaliśmy rozgłaszanie sieci 10.0.0.0/24,
    • przy niektórych trasach pojawia się zapis - Null0.

Osoby, które miały styczność z tym protokołem pewnie już do prawidłowych wniosków doszły i wiedzą w czym tkwi błąd a dla tych, którzy z tym protokołem spotykają się po raz pierwszy już biegnę z wytłumaczeniem.

Wszystkiemu winna jest domyślnie włączona opcja automatycznego podsumowania na granicach dużych sieci (auto-summary). Opcja ta, tak samo jak np. w przypadku protokołu RIP automatycznie podsumowuje rozgłaszane podsieci do ich wartości klasowych. Dlatego np. w tablicy routingu routera R1 znajduje się adres 10.0.0.0/8 a nie 10.0.0.0/24 ponieważ router R2 rozgłaszając tą sieć dokonał jej podsumowania do wartości klasowej. Oczywiście ta sama sytuacja zachodzi w przypadku sieci 192.168.x.x definiowanych w poleceniu network z prefiksem /30 oraz sieci 172.16.x.x z prefiksem /24

Tak więc by zapewnić możliwość pełnej komunikacji w naszej ćwiczebnej sieci należy wyłączyć opcję automatycznego podsumowania. Podsumowanie wyłączamy za pomocą polecenia: no auto-summary wydanym w trybie konfiguracji protokołu routingu.

Po wydaniu polecenia: no auto-summary następuje proces zerwania a następnie ponownego nawiązania relacji sąsiedzkich z routerami - komunikaty konsoli (aby włączyć wyświetlanie informacji o przebiegu procesu EIGRP należy posłużyć się poleceniami: eigrp log-neighbor-changes - zmiana statusu sąsiadów; eigrp log-neighbor-warnings - ostrzeżenia oraz eigrp event-logging - informacje o przebiegu procesu EIGRP tj.: przesyłanych trasach, metrykach oraz trasach instalowanych w tablicy routingu)

Po wydaniu polecenia: no auto-summary na wszystkich trzech routerach możemy przejść do zbadania ich tablic routingu, celem sprawdzenia czy sytuacja uległa poprawie.

Jak można stwierdzić routery posiadają w swoich tablicach routingu trasy do wszystkich sieci a prefiksy tych sieci odpowiadają prefiksom użytym w połączeniu z poleceniem network.

Tak więc wykonajmy ponownie test ping.

Komputer WindowsXP_1

Komputer WindowsXP_2

Komputer WindowsXP_3

Jak można się przekonać wszystko jest OK, wszystkie hosty mogą ze sobą prowadzić komunikację.

To jeszcze na koniec rzut oka na przechwycone pakiety z włączonym podsumowaniem i po wydaniu polecenia: no auto-summary (komunikacja pomiędzy routerem R1 a R2).

Sumaryzacja sieci włączona.

Sumaryzacja sieci wyłączona.

Analiza przechwyconych pakietów dokładnie pokazuje jakie informacje routery pomiędzy sobą przekazywały.

Stan sumaryzacji możemy sprawdzić wydając polecenia: show running-config oraz show ip protocols (przykłady użycia poleceń za chwilę).

Trochę wyżej wcześniej wspominałem o tajemniczym zapisie Null0 znajdującym się w trasie sieci zainstalowanej w tablicy routingu. Pewnie już zauważyłeś (i wyciągnąłeś wnioski) Czytelniku, że zapis ten pojawił się w scenariuszu w którym podsumowanie sieci działa. Tak więc gdzie prowadzi trasa wskazująca na interfejs wyjściowy Null0?

Wróćmy jeszcze raz do tablicy routingu routera R1.

Interfejs Null0 jest drogą donikąd, przez którą trafiają wszystkie odrzucone pakiety. Jak można zaobserwować trasa ta jest trasą podrzędną (pkt. 2) pasującą do wszystkich pakietów trasy nadrzędnej (pkt. 1) oznacza to, że wpis trasy Null0 będzie znajdował się pod wpisem trasy głównej. Odrzucenie pakietów zachodzi gdy trafiające pakiety pasują do trasy nadrzędnej, ale nie znajdują dopasowania w żadnej trasie podrzędnej.

Zastosowanie takiej koncepcji spowodowało, że pakiety które miały trafić do sieci 172.16.1.0/24 został odrzucane. Gdy pakiet o docelowym adresie 172.16.1.10 trafiał do routera, router dopasowywał ten adres do sieci nadrzędnej 172.16.0.0/16 a następnie szukał dopasowania do sieci podrzędnej. Dopasowanie niestety nie następowało dlatego pakiet ten trafiał do kosza.

Warto nadmienić, że sytuacja związana z interfejsem Null0 nastąpi niezależnie od zastosowanego wariantu routingu. Interfejs ten pojawi się zarówno gdy jest prowadzony routing bezklasowy jak i klasowy. Po wyłączeniu sumaryzacji interfejs Null0 nie jest stosowany.

Gdy zapewniliśmy już komunikację pomiędzy wszystkimi hostami w sieci warto jeszcze troszeczkę bliżej przyjrzeć się działaniu algorytmu DUAL. Poniżej na rysunkach przedstawiono etapy wysyłki poszczególnych pakietów w przypadku zaistnienia zmiany w topologii. Zmiana ta została spowodowana wyłączeniem interfejsu ethernetowego routera R1.

Dostęp do sieci 172.16.0.0/24 został utracony, zmiana topologii wymusza na routerze R1 proces powiadomienia o tym zdarzeniu wszystkich swoich sąsiadów, router R1 poprzez swoje interfejsy na których jest ustanowiona przyległość wysyła pakiety aktualizacji (krok 1).

Routery R2 i R3 po otrzymaniu komunikatu z aktualizacją, fakt ten potwierdzają poprzez odesłanie potwierdzenia (krok 2). Router R1 ma pewność, że wysłane pakiety z aktualizacją poprawnie dotarły do sąsiadów.

Router R1 stracił możliwość komunikacji z siecią 172.16.0.0/24 dlatego wysyła do swoich sąsiadów pakiet z zapytaniem czy przypadkiem nie jest znana im droga dotarcia do tej sieci (krok 3). Pakiet z zapytaniem zostaje wysłany ponieważ router R1 nie posiada informacji o trasie zapasowej - trasa ta jest również nazywana dopuszczalnym sukcesorem (pojęcie te zostanie omówione w dalszej części wpisu).

Ponieważ pakiety Query są wysyłane w sposób niezawodny, sąsiedzi do których takie zapytanie dotarło muszą odpowiedzieć potwierdzeniem (pakiet acknowledgement) iż pakiet otrzymali (krok 4).

Po przetworzeniu pakietu Query wysłanego przez router R1 pozostałe routery tworzące przyległość muszą na taki pakiet odpowiedzieć (krok 5). Oczywiście routery (R2, R3) zwracające odpowiedź poinformują router R1, że trasa o którą ten router pytał jest im nie znana.

Pakiety odpowiedzi są również wysyłane w sposób niezawodny dlatego router R1 na te pakiety odpowiada potwierdzeniem (krok 6).

W dalszym ciągu nie wszystkie kwestie związane z algorytmem DUAL zostały wytłumaczone ale za jakąś chwilę do tematu ponownie powrócimy.

Protokół EIGRP działa, nasza sieć jest zbieżna, wszystko jest OK. Ale co zrobić gdy wystąpi problem i wbrew naszym oczekiwaniom informacje o trasach zdalnych pomiędzy routerami nie są wymieniane. Przy rozwiązywaniu ewentualnie mogących pojawić się problemów, pierwszy krok powinniśmy skierować ku sprawdzeniu czy relacje sąsiedzkie z routerami zostały poprawnie nawiązane. Polecenie, które pozwoli nam na sprawdzenie z jakimi routerami sąsiedztwo zostało ustanowione jest komenda: show ip eigrp neighbors (można również do polecenia dodać dodatkowy argument detail, który pozwoli nam na uzyskanie większej ilości informacji). Tak więc sprawdźmy ustanowione przez router R1 przyległości.

Po wydaniu polecenia uzyskujemy informacje:

H - kolejność ustanowionych przyległości,

Address - adres IP sąsiada,

Interface - interfejs lokalny (w tym przypadku interfejsy routera R1) przez, który odbywa się komunikacja z sąsiadem, bądź inaczej interfejs lokalny na którym zostały odebrane pakiety hello,

Hold - aktualny czas wstrzymania, przy domyślnej konfiguracji odliczanie trwa w dół od 15 do 10, gdyż czas wstrzymania jest ustawiony na 15 sekund a co 5 sekund odbierany jest pakiet hello. Każde odebranie nowego pakietu hello resetuje licznik i powoduje rozpoczęcie nowego cyklu odliczania. Jeśli licznik osiągnie wartość 0, router uznaje sąsiada za nieosiągalnego (wyłączonego),

Uptime - czas ustanowienia relacji sąsiedzkiej,

SRT (ang. Smooth Round Trip Timer) i RTO (ang. Retransmit Interval) - czas w milisekundach pomiędzy wysłaniem pakietu do sąsiada a odbiorem potwierdzenia jego dostarczenia,

Q Cnt (ang. Queue Count) - ilość pakietów w kolejce do wysłania, jeśli wartość jest większa od zera, może to sugerować przeciążenie routera lub wolne łącze (zbyt mała szerokość pasma, pakiety EIGRP nie mogą być wysłane ze względu na niską przepustowość łącza). Liczba 0 oznacza brak pakietów protokołu EIGRP w kolejce.

Seq Num (ang. Sequence Number) - numer ostatniego pakietu otrzymanego od sąsiada. Pole wykorzystywane do identyfikacji pakietów, które mogą docierać do routera w różnej kolejności.

Brak na liście sąsiada co do którego mamy pewność, że powinien się znajdować może sugerować popełnienie błędu w konfiguracji - niepoprawny numer procesu bądź pomyłka przy wydaniu polecenia network. Błąd ten można wyłapać sprawdzając bieżącą konfigurację routera (show running-config). Jak również widać odnajdujemy tu również informację o tym, że podsumowanie adresów jest wyłączone (no auto-summary).

Drugą przyczyną może być nieaktywny interfejs - weryfikacja za pomocą polecenia: show ip interface brief bądź skorzystanie z polecenia ping poprzez wysłanie pakietów ICMP na dany interfejs.

Inną przyczyną braku sąsiada może być niepoprawnie skonfigurowany interfejs pasywny (ang. passive interface), skonfigurowany sąsiad statyczny bądź niezgodność w wagach metryki. Wybacz Czytelniku ale na razie te zagadnienia pominę gdyż będą one rozwinięte w dalszej części wpisu.

Poleceniem, które pomoże nam również w określeniu stanu przyległości jest komenda: show ip eigrp interface Po wydaniu komendy zostanie wyświetlona lista interfejsów w rozbiciu na numer procesu na których został włączony protokół EIGRP (to te interfejsy zdefiniowane pośrednio za pomocą adresu sieci w poleceniu network) lecz w tym poleceniu nie są uwzględnione interfejsy pasywne.

Pozycją, którą powinniśmy się zainteresować jest kolumna Peers, która informuje nas o ilości utworzonych przyległości na konkretnym interfejsie.

Dane statystyczne o ilości i rodzaju wysłanych pakietów dostarczy nam polecenie: show ip eigrp traffic

Poleceń weryfikujących działanie protokołu EIGRP jest znacznie więcej ale na razie ze względu na omówione zagadnienia poprzestanę na tych.

Protokół EIGRP dzięki użyciu polecenia: network wszystkich swoich sąsiadów poznaje dynamicznie, każdy router na którym zostały skonfigurowane poprawnie opcje konfiguracyjne swoich sąsiadów pozna automatycznie. Ale oprócz poznania sąsiadów w ten sposób istnieje możliwość wyłączenie dynamicznego tworzenia relacji sąsiedzkich i samemu zdefiniowania z kim router ma taką relację nawiązać. Opcja ta rzadko stosowana choć w pewnych nietypowych sytuacjach może okazać się pomocna np. sieci WAN oparte o Frame Relay. Aby omówić tworzenie relacji sąsiedzkich w oparciu o konfigurację statyczną zmienimy naszą topologię sieci. Schemat sieci wygląda następująco:

Na wszystkich routerach działa protokół EIGRP i sieć jest zbieżna. Poniżej ping wysłany z hosta 192.168.0.10/24

A tablice routingu zawierają wszystkie potrzebne informacje (tablica routingu routera R3)

Nasza sieć działa, przeprowadzona konfiguracja zagwarantowała nam komunikację z wszystkimi hostami w sieci. Wydane polecenie network w połączeniu z użytymi adresami rozgłosiło sieci interfejsów zdefiniowanych na routerze.

Przypuśćmy, że z jakiś powodów musimy zdefiniować relację statyczną pomiędzy routerami R1 a R2. Konfiguracja sąsiada statycznego sprowadza się do wydania na obu routerach polecenia: neighbor <adres_IP_sąsiada> <interfejs> Polecenie wydajemy w trybie konfiguracji routingu.

Relacja statyczna została utworzona. Obserwując uzyskiwane komunikaty w CLI routera można już dojść do interesujących wniosków. Po wydaniu na routerze R1 polecenia: neighbor relacje sąsiedzkie (IP 10.0.0.3 oraz 10.0.0.2) zostają zerwane z powodu zdefiniowania sąsiada w sposób statyczny (Static peer configured). Router w swojej tablicy routingu posiada tylko informację o sieciach połączonych bezpośrednio.

Po przejściu na router R2 i wydaniu polecenia nakazującego utworzenie relacji statycznej z routerem R1, relacja ta zostaje utworzona (Neighbor 10.0.0.1 (FastEthernet0/0) is up: new adjacency) lecz router traci przyległość z routerem R3 (Neighbor 10.0.0.3 (FastEthernet0/0) is down: Static peer configured).

Zbierając to wszystko razem w całość najistotniejszy wniosek, który należy wyciągnąć (część z was już sama pewnie na to wpadła) z tego przykładu to to: że utworzenie relacji statycznej z drugim routerem powodują zerwanie relacji utworzonych dynamicznie. Czyli routery R1 oraz R2 powinny mieć w swojej tablicy routingu sieci ogłaszane przez siebie lecz sieci pochodzące od routera R3 będą już ignorowane. Natomiast router R3 w swojej tablicy routingu nie będzie miał tras prowadzących do sieci za routerami R1 i R2. Aby się przekonać czy tak faktycznie jest sprawdźmy to.

Nasze przypuszczenia okazują się trafne. Utworzenie relacji statycznej przez router powoduje wyłączenie przetwarzania komunikatów grupowych otrzymywanych przez inne routery.

Analizując naszą wcześniejszą topologię dojdziemy do wniosku, że na trzech interfejsach rozgłaszanie sieci za pomocą protokołu EIGRP jest zbędne gdyż nie ma żadnego routera, który mógłby te informację wykorzystać. Mowa tu o interfejsach ethernetowych, każdego z trzech routerów - sieci 172.16.0.0/24, 172.16.1.0/24 oraz 10.0.0.0/24 Sieci te muszą być rozgłaszane a jak już wiesz włączenie tych interfejsów, które reprezentują daną sieć do aktualizacji EIGRP jest jednoznaczne z uruchomieniem na tych interfejsach protokołu EIGRP.

Aby problem ten rozwiązać tj. ogłaszać sieć, ale uniemożliwić tworzenie przyległości na danym interfejsie można skorzystać z dwóch rozwiązań:

• • • za pomocą polecenia network włączamy na interfejsie protokół EIGRP, lecz za pomocą komendy: passive-interface zabraniamy routerowi na wysyłanie pakietów Hello (brak pakietów uniemożliwia utworzenie relacji),
    • całkowicie zrezygnować z polecenia network a trasę ogłaszać za pomocą mechanizmu redystrybucji trasy sieci bezpośrednio podłączonej do routera - polecenie: redistibute connected.

Skorzystanie z interfejsu pasywnego powoduje na danym interfejsie wyłączenie wszelkich komunikatów routingu (zarówno komunikaty grupowe i jednostkowe) a jednocześnie zabrania routerowi na tym interfejsie ustanowienie relacji sąsiedzkiej. Idea interfejsu pasywnego została już zastosowana przy protokole RIP lecz w połączeniu z tym protokołem polecenie passive-interface blokowało wysyłanie aktualizacji okresowych ale w dalszym ciągu router na zdefiniowanym interfejsie aktualizacje odbierał i je przetwarzał.

Konfiguracja routera jest prosta wystarczy tylko w trybie konfiguracji procesu routingu wydać polecenie: passive-interface <nazwa_interfejsu> by proces EIGRP na tym interfejsie został wyłączony.

Poniżej przedstawiono przechwycone pakiety na interfejsie f0/0 routera R1. Jak można zauważyć pakiety Hello są wysyłane regularnie co 5 sekund. Po wydaniu polecenia passive-interface na tym interfejsie router wstrzymuje wysyłanie pakietów Hello - ostatni pakiet został wysłany o 21:18:25 (hh:mm:ss).

Informację o skonfigurowanych interfejsach pasywnych znajdziemy m.in. w konfiguracji bieżącej

a także po wydaniu polecenia: show ip eigrp interfaces. Brak na liście interfejsu f0/0 oznacza, że jest on w stanie pasywnym.

Jest jeszcze jedno polecenie: show ip protocols, które pozwoli nam sprawdzić stan interfejsów co do których wydano komendę: passive-interface. Polecenie to wymaga szerszego omówienia, gdyż dostarcza ono bardzo wiele użytecznych informacji odnośnie protokołu EIGRP. Część informacji uzyskanych dzięki poleceniu została tylko zasygnalizowana gdyż do komendy tej będziemy często się odwoływać w dalszej części wpisu a także w danych tych znajdziesz potwierdzenie poleceń konfiguracyjnych omówionych wcześniej.

1 - informacja o włączonym filtrowaniu aktualizacji wychodzących (nie ustawione),

2 - informacja o włączonym filtrowaniu aktualizacji przychodzących (nie ustawione),

3 - domyślne sieci oznaczone dla aktualizacji wychodzących i przychodzących,

4 - wagi metryki,

5 - maksymalny licznik skoków,

6 - odchylenie metryki EIGRP,

7 - numer procesu EIGRP,

8 - informacja o automatycznym podsumowaniu (podsumowanie wyłączone). W przypadku gdy podsumowanie jest aktywne informacje będą poszerzone o adresy sieci, interfejsy, wartości metryk, co do których opcja ma zastosowanie.

9 - maksymalna liczba tras równorzędnych (z tą samą metryką)(4),

10 - adresy sieci rozgłaszanych w procesie EIGRP,

11 - interfejsy pasywne,

12 - adresy sąsiadów (skąd są otrzymywane aktualizacje) wraz z dystansem administracyjnym: 90 (trasy wewnętrzne - internal), 170 (trasy zewnętrzne - external) oraz 5 (trasy podsumowane - summary).

Drugą opcją jest redystrybucja trasy bezpośrednio połączonej z routerem za pomocą polecenia: redistribute connected. Operację tą wykonamy na routerze R2.

Rozgłaszać będziemy sieć 10.0.0.0/24. Sieć jest uwzględniona w poleceniu network więc zaczniemy od wyłączenia jej - polecenie: no network 10.0.0.0 0.0.0.255

Sieć po wydaniu polecenia przestaje być rozgłaszana. By się upewnić, że tak faktycznie jest sprawdzamy tablicę routingu routera R1. Jak można zaobserwować na zrzucie poniżej sieć ta została z tablicy routingu usunięta.

Spróbujmy zatem tą sieć rozgłosić z wykorzystaniem redystrybucji trasy. Tu od razu zaznaczę, że podam tylko gotowe rozwiązanie gdyż opiera się ono o treści jeszcze nie opisywane przeze mnie a niestety kompletne wytłumaczenie użytych opcji konfiguracyjnych daleko wykracza poza tematykę tego wpisu - są to zagadnienia, które poruszę w następnych wpisach.

1 - tworzę listę prostą ACL (mechanizm filtrowania ruchu sieciowego ang. Access Control Lists), numer tej listy to 10 w której zezwalam (permit) na ruch sieciowy odnoszący się do sieci 10.0.0.0/24 (choć w tym kontekście powinienem powiedzieć, że lista ta będzie odpowiedzialna za definicję ogłaszanej trasy),

2 - w kolejnym kroku konfigurujemy mapę routingu (router-map) o nazwie sieci z numerem sekwencyjnym 20,

3 - mapa obejmuje ruch zdefiniowany przez listę ACL 10,

4 - ustalamy metrykę ogłaszanej trasy a raczej składowe, które posłużą do jej obliczenia. Wartości według kolejności to (wartości te będziemy również wykorzystywać gdy będziemy chcieli rozgłosić trasy pochodzące z innych protokołów routingu a jeszcze zajmiemy się nimi dokładniej jak będę omawiać metrykę protokołu EIGRP):

szerokość pasma (ang. bandwidth) wyrażana w kilobitach na sekundę, wartość zawiera się w przedziale od 1 do 4294967295,

opóźnienie (ang. delay) - średnie opóźnienie pakietu na danej trasie, jednostka to 10 mikrosekund, wartość zawiera się w przedziale od 1 do 4294967295

dostępność (ang. reliability) - wartość określająca prawdopodobieństwo, że dana trasa jest odporna na awarie. Wartość zawiera się w przedziale od 0 do 255 gdzie wartość 255 oznacza trasę, która jest 100% pewna,

pasmo efektywne, obciążenie (ang. effective bandwidth, loading) - dostępność pasma, wartość od 0 do 255 gdzie 255 oznacza maksymalne wykorzystanie pasma,

maksymalna jednostka transmisyjna (ang. MTU) - wartość maksymalnej jednostki transmisyjnej, wartość zawiera się w przedziale od 1 do 4294967295

5 - wyłączamy (deny) wszystkie inne sieci,

6 - w trybie konfiguracji routingu zdefiniowaną mapę routingu rozgłaszamy za pomocą polecenia: redistribute connected

Po wydaniu polecenia nakazującego redystrybucję trasy bezpośrednio podłączonej do routera R2 (sieć 10.0.0.0/24), protokół EIGRP do sąsiadów wysyła pakiety aktualizujące zawierające informacje o ogłaszanej sieci.

Sprawdzenie tablicy routingu routera R1 uwidacznia nam fakt istnienia trasy do sieci 10.0.0.0/24, komunikacja pomiędzy hostami została przywrócona.

Rozwiązanie to jest znacznie rzadziej stosowane (łatwiej jest wykorzystać interfejs pasywny), choć oczywiście tak jak pokazałem można z niego skorzystać. Wadą tego rozwiązania jest ogłaszanie drogi do sieci zdalnej za pomocą trasy zewnętrznej (stąd w tablicy routingu routera R1 zapis D EX). Trasa zewnętrzna jest ogłaszana z większym dystansem administracyjnym (170) oznacza to, że znacznie mniej chętnie będzie wybierana gdy pojawi się inna alternatywna droga.

Dla przypomnienia inne wartość dystansów administracyjnych (na szaro dystanse administracyjne związane z protokołem EIGRP).

Poniżej jeszcze przykład przechwyconego pakietu niosącego ze sobą informację o trasie zewnętrznej (typ 0x0103 = pkt. 3). Pakiet aktualizacji (pkt. 2) został wysłany z routera R2 (pkt. 1). Aktualizacja zawiera składowe potrzebne do obliczenia metryki trasy (pkt. 4).

Podsumowując temat ustalania przyległości najważniejsze informacje zostały zebrane w tabeli poniżej aby mieć punkt odniesienia dane te zostały porównane z już opisywanym przeze mnie protokołem OSPF.

Protokół EIGRP wspiera uwierzytelnianie, które polega na zdefiniowaniu na każdym z routerów tego samego współdzielonego klucza (ang. preshared key, PSK). Na podstawie klucza generowany jest skrót MD5, skrót ten jest dołączany do każdego komunikatu EIGRP. W przypadku odebrania tak podpisanego komunikatu, router wartość skrótu z komunikatu porównuje z wartością lokalną skrótu, gdy wartości są identyczne następuje uwierzytelnienie. W przypadku wystąpienia niezgodności pakiet jest odrzucany. Efektem odrzucenia pakietu jest niemożność utworzenia relacji sąsiedzkiej z routerem.

Co warto zaznaczyć, pakiety za pomocą zdefiniowanego klucza nie są w żaden sposób szyfrowane, co umożliwia ich odczytanie. Zabezpieczenie te ma na celu uniemożliwienie utworzenia nie autoryzowanej przyległości i tym samy ogłaszania informacji o fałszywych trasach.

Włączenie uwierzytelnienia pomiędzy routerami następuje według listeningu pokazanego poniżej - uwierzytelnienie pomiędzy routerem R1 (interfejs s0/0) a R3 (interfejs s0/1).

1 - w trybie konfiguracji globalnej za pomocą polecenia: key chain <nazwa> tworzymy łańcuch (nazwa łańcucha może na różnych routerach może przyjmować inne nazwy),

2 - w trybie konfiguracji łańcucha tworzymy przynajmniej jeden klucz - polecenie: key <numer_klucza> (w literaturze doszukałem się, że numery kluczy na ruterach mogą przyjmować różne wartości lecz po skonfigurowaniu ruterów z innymi wartościami kluczy protokół EIGRP nie mógł ustanowić uwierzytelnienia - rysunek za chwilę),

3 - ustalamy hasło, które będzie wykorzystane w procesie uwierzytelnienia - komenda: key-string <hasło>,

4 - przechodzimy do konfiguracji interfejsu na którym będzie realizowane uwierzytelnienie,

5 - w trybie konfiguracji interfejsu wydajemy polecenie: ip authentication mode egrp <numer_procesu> md5,

6 - po wydaniu polecenia z pkt. 5 ustanowiona przyległość z routerem R3 zostaje zerwana,

7 - za pomocą polecenia: ip authentication key-chain egrp <numer_procesu> <nazwa_łańcucha> wskazujemy prawidłowy łańcuch klucza.

Po włączeniu na interfejsie s0/0 routera R1 uwierzytelnienia, wszelka wymiana pakietów Hello z routerem R3 zostaje zatrzymana (choć pakiety Hello nadal są przez oba routery wysyłane, brak możliwości „dogadania się” jest spowodowany inną naturą przesyłanych danych), czego skutkiem jest niemożność bezpośredniego przesłania do routera R1 informacji o sieciach znanych routerowi R3. Sieć pomimo braku relacji sąsiedzkiej pomiędzy routerem R1 a R3 nadal jest zbieżna (host WindowsXP_1 ma możliwość komunikacji z hostem WindowsXP_3), ponieważ istnieje alternatywna droga , którą pakiety mogą podróżować do routera R3 (trasa prowadzi poprzez router R2). Fakt ten można zweryfikować przeglądają tablicę routingu routera R1, jak widać poniżej router R1 pakiety zaadresowane do sieci 172.16.1.0/24 wyśle na adres następnego skoku 192.168.0.2 (interfejs s0/1 routera R2).

Włączenie uwierzytelnienia powoduje dodanie dodatkowych danych do pakietu Hello. Dane te niosą ze sobą informacje o wymaganym uwierzytelnieniu. Obecność dodatkowych informacji można zweryfikować przeglądając przechwycony pakiet Hello.

Poprawność konfiguracji możemy zweryfikować za pomocą polecenia: show key chain Wydanie polecenia pokaże nam zdefiniowany łańcuch - informacja o nazwie łańcucha, numerze klucza oraz haśle.

Polecenie: debug eigrp packets włączy proces debugowania wysyłanych/odbieranych pakietów EIGRP. Informacje jakie uzyskamy dzięki wydaniu polecenia możemy użyć do rozwiązania problemów z niemożnością utworzenia przyległości. Na rysunku poniżej włączony proces debugowania, który uwidacznia błąd uwierzytelnienia (opcode =5 missing authentication), błąd ten jest spowodowany brakiem konfiguracji na routerze R3.

Poniżej jeszcze jeden rodzaj błędu (opcode=5 invalid authentication), błąd ten został spowodowany różnym ustawieniem wartości numeru klucza.

Po skonfigurowaniu na routerze R1 uwierzytelnienia proces trzeba powtórzyć na routerze R3 (zwróć uwagę, że została skonfigurowana inna nazwa łańcucha).

Po włączeniu na interfejsie s0/1 routera R3 uwierzytelnienia uzyskujemy informację o utworzeniu nowej przyległości (rysunek powyżej - new adjacency) oraz włączony proces debugowania nie uwidacznia, żadnych błędów (rysunek poniżej).

Poprawność wydanych komend, możemy również zweryfikować poprzez ponowne przeglądnięcie tablicy routingu routera R1. Jak można zauważyć tablica routingu uległa zmianie i dostęp do sieci 172.16.1.0/24 jest znów realizowany poprzez router R3 (interfejs s0/1, IP 192.168.2.2)

Aby uniemożliwić odgadnięcie klucza EIGRP bądź jego złamanie można wprowadzić dodatkowy mechanizm polegający na zdefiniowaniu kilku kluczy cały trik polega na tym, że za pomocą dodatkowych komend: accept-lifetime oraz send-lifetime określamy ważność klucza oraz czas jego rozsyłania. Po konfiguracji kilku kluczy w zależności od zdefiniowanego czasu klucze są odpowiednio stosowane nie przerywając działania urządzeń sieciowych.

W naszej topologii taki łańcuch kluczy został zdefiniowany na routerach R1 oraz R3.

Na urządzeniu (router R1) zostały zdefiniowane dwa klucze odpowiednio key 1 (hasło: cisco) i key 2 (hasło: qwerty) czas żywotności kluczy został ustawiony następująco:

key 1: klucz będzie akceptowalny od 21:30 19.04.2015 do 21:40 19.04.2015 (polecenie: accept-lifetime 21:30:00 April 19 2015 21:40:00 April 19 2015) czas jego rozsyłania mieści się w tych samych ramach czasowych (polecenie: send-lifetime 21:30:00 April 19 2015 21:40:00 April 19 2015)

key 2: klucz będzie akceptowalny od 21:40:15 19.04.2015 do 21:50 19.04.2015 (polecenie: accept-lifetime 21:40:15 April 19 2015 21:50:00 April 19 2015) a czas jego rozsyłania jest identyczny (polecenie: send-lifetime 21:40:15 April 19 2015 22:50:00 April 19 2015)

Oczywiście taką samą konfigurację musimy przeprowadzić na routerze R3.

Po nastaniu godziny 21:30 19.04.2015 pierwszy klucz przechodzi w stan aktywny i rozpoczyna się proces uwierzytelnienia. To że klucz faktycznie jest w użyciu zdradza nam włączony proces debugowania pakietów EIGRP (polecenie: debug eigrp packet)

Dodatkowo, który klucz jest aktualnie w użyciu sprawdzimy wydając polecenie: show key chain, zapis przy kluczu: valid now

Śledząc na poniższym zrzucie znaczniki czasu i kolejność operacji wykonywanych przez router stwierdzamy, że o godz. 21:29:56 router do uwierzytelnienia używał klucza id=1 (pkt. 1) O godzinie 21:400:00 klucz ten traci ważność i pakiet od routera R1 zostaje odrzucony z powodu błędu uwierzytelnienia (pkt .2).

Przez kolejne 19 sekund relacja sąsiedzka z routerem R1 jest zawieszona. Ponowne nawiązanie relacji następuje o 21.40:19 kiedy to router otrzymuje pakiet Hello od routera R1 a klucz o identyfikatorze id=2 uzyskał ważność (pkt. 3).

Następuje wymiana pakietów EIGRP i routery R1 i R3 znowu są sąsiadami (pkt. 4)

Wywołanie polecenia: show key chain potwierdza, że aktywnym kluczem biorącym udział w procesie uwierzytelnienia jest klucz: key 2

Aby uniknąć przestoju w postaci zerwanej relacji sąsiedzkiej musimy manipulować czasem ważności klucza i czasem jego wysyłania aby proces zmiany klucza uwierzytelnienia nie wpłynął na proces routingu.

W protokole EIGRP istniej możliwość zdefiniowania jaki maksymalny procent przepustowości łącza może wykorzystywać proces EIGRP. Domyślne ustawienie mechanizmu EIGRP definiuje ten parametr na 50% (wymiana pakietów hello, uaktualnienia itd.). W przedstawionych przykładach w celu ustalenia odpowiedniej wartości metryki można było do tego celu wykorzystać zmianę szerokości pasma danego interfejsu. Czasem by osiągnąć zamierzony cel ustalono przepustowość łącza na wartość mniejszą niż rzeczywista. Zdefiniowanie niskiej wartości łącza będzie skutkowało zmniejszeniem maksymalnej wartość szerokości pasma do jakiej protokół EIGRP może prowadzić skuteczną wymianę informacji z swoimi sąsiadami. Aby uniknąć sytuacji w której nałożone ograniczenie spowoduje problemy z wymianą informacji związanych z działaniem protokołu EIGRP można zdefiniować prawo do wykorzystania większej szerokości pasma.

W przykładzie poniżej polecenie: bandwidth definiuje szerokość pasma interfejsu na 64 kb/s, domyślne ustawienie powoduje, że proces EIGRP może maksymalnie wykorzystać 50% z zdefiniowanej wartości czyli 32 kb/s. Wartość przepustowości interfejsu jest w rzeczywistości większa a polecenie: bandwidth zostało użyte w celu wpłynięcia na metrykę. Aby zwiększyć procentowy udział możliwego do wykorzystania pasma przez protokół EIGRP należy posłużyć się poleceniem: ip bandwidth-percent eigrp <numer_procesu> <wartość_procentowa> Polecenie wydajemy w trybie konfiguracji interfejsu.

Po wydaniu polecenia proces EIGRP będzie miał do wykorzystania pasmo o szerokości 128 kb/s gdyż procent maksymalnego wykorzystania pasma został ustalony na 200%

Metryka EIGRP

Dla przypomnienia metryką trasy jest wartość służąca do określenia jak najlepszej drogi dotarcia do sieci zdalnej. W sieciach zdarza się sytuacja w której router będzie znał wiele dróg, którymi może przesłać pakiet do sieci docelowej a wybór tej najlepszej, najszybszej i najefektywniejszej będzie zależał właśnie od metryki. Im metryka niższa tym trasa lepsza. Co warto jeszcze przypomnieć to to, że metryki wyliczane poprzez różne protokołu routingu są wartościami, którymi ze sobą porównywać nie wolno, z tego prostego powodu, że wartości wyliczone poprzez np. protokół RIP mają się ni jak do tych obliczonych z wykorzystaniem protokołu EIGRP. Sposób ustalania metryki dla każdego z protokołów jest po prostu inny a otrzymane wartości są po prostu nieporównywalne ze sobą.

Protokół EIGRP metrykę oblicza wg. następujących wzorów:

Wzór domyślny:

Wzór pełny:

By przejść do przykładów obliczenia metryki najpierw musimy rozwikłać wszystkie składowe, które są używane w wzorach i wytłumaczyć czemu są dwa wzory.

Wzór pełny zawiera wartości od K1 do K5, wartości te nazywane są składowymi metryki EIGRP. W domyślnej konfiguracji składowe te powiązane są z parametrami łącza i są im przypisane wartości, które określają czy poszczególny parametr łącza będzie brał udział w wyliczeniu metryki - wartością od K1 do K5 jest przypisana wartość 0 lub 1. Wagi oraz domyślne wartości K w protokole EIGRP przedstawiają się następująco:

• • • K1 - szerokość pasma - przypisana wartość: 1
    • K2 - obciążenie - przypisana wartość: 0
    • K3 - opóźnienie - przypisana wartość: 1
    • K4 - niezawodność - przypisana wartość: 0
    • K5 - niezawodność - przypisana wartość: 0

I tu mamy odpowiedź skąd się wziął wzór domyślny - gdy do wzoru pełnego podstawisz wartości K to wzór ten ulegnie skróceniu do wzoru domyślnego, gdyż poszczególne części wzoru po prostu przyjmą wartość 0. Czyli metryka EIGRP jest parametrem złożonym i może (nie musi) uwzględniać takie wielkości jak: pasmo, opóźnienie, obciążenie czy niezawodność. W niektórych publikacjach można znaleźć informacje, że do obliczenia metryki jest brana również wartość MTU, ale jest to błąd. Jak sam możesz stwierdzić Czytelniku wartość MTU nie jest uwzględniona w żadnym z podanych wzorów.

Aby sprawdzić wartości składowych metryki należy posłużyć się poleceniem: show ip protocols

Jak widać powyżej na routerze R1 składowe metryki K przyjmują wartości domyślne.

Gdy już potrafimy określić wartość metryk składowych czas przyjrzeć się parametrom łącza (interfejsu) powiązanych z tymi składowymi. Wartości tych parametrów poznamy po wydaniu polecenia: show interface <nazwa_interfejsu>

Szerokość pasma (BW - pkt. 1) - jest to wartość, która jest używana do obliczania metryki nie tylko rzez protokół EIGRP lecz także np. prze OSPF. Wielkość ta wyrażona jest w kilobitach na sekundę (kb/s). Przy zmianie szerokości pasma warto zaznaczyć, że zmiana tego parametru w żaden sposób nie wpłynie na rzeczywistą używaną szerokość pasma łącza. Czyli pasmo BW nie musi odzwierciedlać faktycznej szerokość pasma na interfejsie, choć oczywiście warto zadbać o to by wartości te były równe.

Domyślne szerokości pasma:

• • • 100M ATM - 100000 kb/s
    • Gigabit Ethernet - 100000 kb/s
    • Fast Ethernet - 100000 kb/s
    • FDDI - 100000 kb/s
    • HSSI - 45,045 kb/s
    • 16M Token Ring - 16,000 kb/s
    • Ethernet - 10,000 kb/s
    • T1 (łącze seregowe - serialowe) - 1544 kb/s
    • DS0 - 64 kb/s
    • 56K - 56 kb/s

Opóźnienie (DLY - pkt. 2) - miara czasu jaki pakiet potrzebuje, aby zostać przesłany przez łącze. Wartość podawana w mikrosekundach (1 μs = 10^-6 s). Wartość ta jest przypisywana domyślnie w zależności od typu połączenia (technologii jaka jest używana do zestawienia połączenia) czyli rzeczywista wartość opóźnienia nie jest w żaden sposób mierzona przez router.

Wartość opóźnień w zależności od typu łącza zebrano poniżej:

• • • Gigabit Ethernet - 10 μs
    • 100M ATM - 100 μs
    • Fast Ethernet - 100 μs
    • FDDI - 100 μs
    • 1HSSI - 20000 μs
    • 16M Token Ring - 630 μs
    • Ethernet - 1000 μs
    • T1 (łącze seregowe - serialowe) - 20000 μs
    • 512K - 20000 μs
    • DSO - 20000 μs
    • 56K - 20000 μs

Niezawodność (reliability - pkt. 3) - miara prawdopodobieństwa, że link ulegnie uszkodzeniu. Wartość ta jest mierzona prze router (5 minutowa średnia ważona) i przyjmuje wartość z zakresu od 0 do 255. Im wartość wyższa tym lepiej dla metryki. Oznacza to, że przy 1 łącze jest niepewne a przy 255 niezawodne. Po wydaniu polecenia: show interface <nazwa_interfejsu> można zauważyć, że parametr ten podawany jest w postaci ułamka (zmienia się licznik, mianownik ustawiony na 255) ale wykorzystując informacje zaprezentowane w zdaniu powyżej im ułamek ma wartość wyższą tym bardziej niezawodne łącze (wszak wartość 255/255 jest liczbą większą od 1/255). Niezawodność w literaturze określana jest również jako dostępność.

Obciążenie (load - pkt. 4) - odzwierciedla ilość ruchu na linku, podobnie jak w przypadku niezawodności, obciążeniu jest przypisywana wartość od 1 do 255 lecz tu mamy do czynienia z sytuacją odwrotną, oznacza to że im niższa wartość, tym lepiej dla metryki. Obciążenie jest również parametrem mierzonym przez router i tak samo jak dostępność podawana w formie ułamka o mianowniku równym 255 choć w rozbiciu na składowe txload (ruch wychodzący) i rxload (ruch przychodzący). Tak więc zapis 1/255 oznacz interfejs obciążony w stopniu minimalnym, natomiast zapis 255/255 łącze wykorzystywane w stu procentach.

OK omówiliśmy wszystkie składowe wzorów tak więc pora przejść do przykładów i samemu spróbować obliczyć metrykę.

Zanim jednak przejdziemy do obliczeń jeszcze raz przypomnę topologię naszej sieci lecz z naniesionymi informacjami, które będą nam potrzebne do wyliczenia metryki.

W pierwszym przykładzie zajmiemy się trasą do sieci 172.16.1.0/24 z punktu widzenia routera R1. To sprawdźmy jaką metrykę obliczył router R1.

Router R1 do rozważanej sieci metrykę ustalił na wartość 2195456.

Spróbujmy zatem metrykę obliczyć sami.

Najlepsza trasa do sieci 172.16.1.0/24 według routera R1 prowadzi poprzez router R3 (via 192.168.2.2) a router z rozpatrywaną siecią jest już połączony bezpośrednio. Tak więc naszym pierwszym krokiem jest ustalenie łącza z najwolniejszą zdefiniowaną szerokością pasma. Najwolniejsze łącze jest pomiędzy routerami BW 1544 kb/s i tą wartość będziemy wykorzystywali do obliczenia metryki. Zanim jednak będziemy mogli użyć tej wartości trzeba jeszcze wykonać jedną operację a mianowicie do wzoru jest podstawiana wartość wyliczona według równania:

Zabieg ten ma jeden cel a mianowicie spowodowanie, że wyższe wartości szerokości pasma uzyskają niższą metrykę a tam gdzie wartość pasma jest niższa wartość metryki będzie większa.

Podstawiając dane do wzoru otrzymamy: 10000000/1544= 6476,683938

Reszta jest odrzucana do wzoru zostanie podstawione: 6476

Kolejnym etapem jest wykonanie sumowania wszystkich opóźnień:

• • • trasa pomiędzy routerem R1 a R3 - DLY 20000 mikrosekund (łącze serialowe),
    • trasa do sieci 172.16.1.0/24 z routera R3 - DLY 1000 mikrosekund (łącze Ethernet).

Tak więc suma opóźnień = 20000+1000=21000 mikrosekund

Wynik ten dzielimy przez 10 ponieważ do wzoru należy podstawić wartość wyrażoną w dziesiątkach mikrosekund.

suma opóźnień = 21000/10=2100 jednostka: 10 mikrosekund

Wykonaliśmy wszystkie niezbędne przekształcenia możemy wartości podstawiać do wzoru:

gdzie:

K1 = 1; K3 = 1

Metryka została obliczona i jest zgodna z tą wyznaczoną przez router R1.

No to jeszcze jeden przykład, ale żeby nie było za prosto zostały zmienione domyślne wartość wagi metryki, wszystkie wartości K zostały ustawione na 1

W tym przykładzie rozważymy ten sam przypadek co w przykładzie powyższym, sprawdźmy jak wygląda metryka po zmianie wag metryki.

Nowo wyliczona metryka dla trasy do sieci 172.16.1.0/24 z perspektywy routera R1 wynosi: 8601 a trasa tak jak poprzednio wykorzystuje router R3

Trasa z najwolniejszym łączem to trasa pomiędzy routerami R1 a R3 - BW 1544 kb/s co po uwzględnieniu referencyjnej szerokości pasma da nam wartość: 10000000/1544=6476,683938

Reszta jest odrzucana do wzoru zostanie podstawione: 6476

Suma opóźnień nie ulega zmianie i tak jak w poprzednim przykładzie wynosi:

suma opóźnień = 21000/10=2100 jednostka: 10 mikrosekund

Wartości niezawodność oraz obciążenie poznamy po wydaniu polecenia: show interface <nazwa_interfejsu>

Niezawodność (reliability) wynosi: 255

Obciążenie (load) wynosi: 1

Znamy wszystkie wartości tak więc nie pozostało nic innego jak je podstawić do wzoru:

po podstawieniu:

gdzie: K1=1; K2=1; K3=1; K4=1; K5=1 otrzymujemy:

po uproszczeniu:

po uproszczeniu:

aby w końcu dać wynik:

Otrzymany wynik po odrzuceniu reszty jest tożsamy z tym, który wyliczył router R1.

Wartości K nie powinniśmy zmieniać bez naprawdę dobrego powodu a jeśli zmieniamy – to na wszystkich routerach tak samo. Jest to spowodowane tym, że wartości niezawodność oraz obciążenie są przez router wyliczane dynamicznie co będzie np. w przypadku dużego obciążenia sieci powodowało ich zmianę a w konsekwencji będzie prowadzić do zmiany wyliczanej metryki. Zmiana metryki zaś w przypadku sieci w których jest zapewniona redundancja (różne trasy do sieci zdalnej) spowoduje zmiany w tablicy routingu na trasę z korzystniejszą metryką. W przypadku spadku ilości przesyłanych informacji wcześniej zdefiniowana trasa będzie znów uwzględniana jako ta bardziej korzystniejsza. Gdy sytuacja ta będzie się cyklicznie powtarzać trasa w przypadku dużego obciążenia będzie usuwana z tablicy routingu a w przypadku ustania obciążenia znów dodawana. W literaturze takie zjawisko jest określane pojęciem migotania trasy (ang. route flapping).

OK dużo już wiemy na temat protokołu routingu jakim jest EIGRP ale nadal pewne kwestie nie zostały przeze mnie dopowiedziane lub całkiem zamierzenie pominięte. Omawiając protokół EIGRP nie można zapomnieć o takich pojęciach jak: sukcesor, dopuszczalny sukcesor, odległość ogłaszana, dopuszczalna odległość czy na czym polega warunek dopuszczalności. Tak więc zostało nam jeszcze parę zagadnień a i tak nie wyczerpiemy tematu do końca. To do roboty i sukcesywnie postaram się omówić powyższe zagadnienia.

Zacznijmy od pojęcia sukcesora. Sukcesor (ang. successor) to tak naprawdę sąsiedni router do którego prześlemy pakiety, celem dostarczenia ich do docelowej sieci. Adresem IP sukcesora jest adres znajdujący się w tablicy routingu routera po słowie via.

Z pojęciem sukcesora wiąże się pojęcie dopuszczalnego sukcesora (ang. feasible successor) czyli sąsiada (router z którym jest ustanowiona przyległość), który tak jak sukcesor zna drogę do sieci docelowej. Przy czym ważne jest aby trasa ta była wolna od pętli i spełniała warunek dopuszczalności (o warunku za chwilkę).

Dopuszczalna odległość (ang. feasible distance, FD) to koszt dotarcia do danej sieci zdalnej - brzmi znajomo? Tak więc jest to po prostu najkorzystniejsza obliczona metryka.

Ogłaszana odległość (ang. reported distance, RD) jest to metryka, którą ogłasza dany router powiadając sąsiada o koszcie (z własnego punktu widzenia) dotarcia do sieci zdalnej.

Zaś definicja warunku dopuszczalności brzmi następująco: warunek ten zostaje spełniony, gdy wartość ogłaszanej odległości przez sąsiada dotarcia do danej sieci zdalnej jest mniejsza od dopuszczalnej odległości routera z punktu którego rozważamy koszt. Bądź inaczej gdy metryka sąsiada wyliczona do danej sieci jest mniejsza od metryki routera który tą sieć musi osiągnąć.

Wiem, że pojęcia te początkującym mogą sprawić trudność (w szczególności warunek dopuszczalność – bo o co chodzi) tak więc omówmy je jeszcze raz na przykładzie naszej testowej topologii. Aby wprowadzić pewne urozmaicenie i zróżnicowanie prędkości połączeń pomiędzy routerami zostały zmodyfikowane i prezentują się następująco:

Rozważmy o to taką sytuację - Router R1 zna drogę do sieci 10.0.0.0/24 poprzez router R2, który jest dla niego sukcesorem (po słowie via znajduje się interfejs s0/1 routera R2). Dopuszczalna odległość wynosi: 2195456

Na skutek awarii łącze pomiędzy routerami R1 i R2 przestaje funkcjonować. Nasuwa się pytanie czy router R3 jest dopuszczalnym sukcesorem dla routera R1 odnośnie trasy do sieci 10.0.0.0/24 (analizując topologię wiemy, że router R3 zna drogę do rozważanej sieci ale to wcale nie oznacza, że trasa prowadząca przez ten router będzie spełniała warunek dopuszczalności i tym samym będąc trasą alternatywną dla routera R1).

Analizując tablicę routingu routera R3 dowiadujemy się, że dopuszczalna odległość do rozważanej trasy (10.0.0.0/24) z punktu widzenia routera R3 wynosi 3037440 (FD).

Odległość ta jest ogłaszana routerowi R1 jako wartość RD.

Mamy wszystkie dane sprawdźmy czy warunek dopuszczalności dla sieci 10.0.0.0/24 został sprawdzony:

warunek dopuszczalności = FD (z punktu widzenia routera R1, sukcesor R2) > RD (informacja od sąsiada R3)

warunek dopuszczalności = 2195456 > 3037440

Jak widać warunek nie zostaje spełniony i router R3 dla routera R1 nie będzie dopuszczalnym sukcesorem.

Tak więc w przypadku awarii algorytm DUAL będzie musiał być przeliczany na nowo. Gdyby router R3 był dopuszczalnym sukcesorem zmiana trasy nastąpiłaby prawie natychmiast nie powodując przestoju sieci.

Informacje o wszystkich sukcesorach (również tych dopuszczalnych), wyliczanych odległościach są przechowywane w tzw. tablicy topologii EIGRP (ang. topology database) a dostęp do tej bazy uzyskamy po wydaniu polecenia: show ip eigrp topology

Analiza danych przekonuje nas o prawidłowości przeprowadzonych obliczeń, jak widać trasa poprzez router R3 nie została uwzględniona.

Zatrzymajmy się chwilkę na tablicy topologii i omówmy informacje się w niej znajdujące:

Kody - przy każdej trasie znajduje się kod, który oznacza aktualny stan trasy. Analizując rysunek powyżej stwierdzamy, że przy wszystkich trasach została umieszczona litera P czyli oznacza to, że trasa jest w stanie pasywnym (ang. passive state). Stan pasywny jest najbardziej pożądanym stanem gdyż oznacza, że trasa jest stabilna.

Adres sieci - informacja powielona w tablicy routingu, oznaczającą adres sieci docelowej

Liczba sukcesorów - wartość oznaczająca liczbę sukcesorów dla danej sieci. Przy wpisie tym w większości przypadków widnieje wartość 1. W przypadku tras dla których obliczona metryka przyjmie jednakową wartość, liczba dostępnych sukcesorów będzie odpowiadać liczbie tras z jednakową metryką.

FD is <wartość> - dopuszczalna odległość obliczona do sieci docelowej (jej metryka).

via <adres_IP> bądź Connected <nazwa_interfejsu> - adres następnego skoku bądź interfejs (sieć połączona bezpośrednio) przez, który należy przesłać pakiety by trafiły do sieci docelowej (informacja ta znajduje się również w tablicy routingu).

is <metryka> - obliczona dopuszczalna odległość do sieci - w naszym przypadku 2195456, sieć 10.0.0.0/24.

(<metryka/dopuszczalna odległość>/<ogłaszana odległość sukcesora>) – wyliczona metryka/koszt dotarcia routera R2 do sieci 10.0.0.0/24, koszt jest ogłaszany routerowi R1.

<interfejs> - interfejs wyjściowy (lokalny), prowadzący do sieci.

Gdy istnieje kolejny wpis oznacza to, że dla danej sieci istnieje dopuszczalny sukcesor. Jak było wcześniej przedstawione dla sieci tej dopuszczalny sukcesor nie istnieje gdyż nie został spełniony warunek dopuszczalności (2195456 > 3037440).

Jak zostało napisane kilka wersów wyżej liczba sukcesorów z reguły wynosi 1, inne wartości pojawią się tylko w przypadku gdy do danej sieci prowadzą różne trasy lecz trasy muszą mieć tą samą wartość metryki i taka sytuacja poniżej. Do sieci 192.168.1.0/30 z punktu widzenia routera R1 prowadzą dwie trasy z taką samą dopuszczalną odległością dlatego liczba sukcesorów wynosi 2 (sytuacja taka nastąpiła ponieważ wartość szerokości pasma pomiędzy wszystkimi routerami jest taka sama).

Pomimo braku dopuszczalnego sukcesora do sieci 10.0.0.0/24 wydając polecenie: show ip eigrp topology <sieć> uzyskamy informację o wszystkich trasach, które prowadzą do danej sieci nawet tych, dla których warunek dopuszczalności nie został spełniony.

Analiza danych uwidacznia nam fakt istnienia dwóch tras prowadzących do sieci 10.0.0.0/24 przy czym jedna jest sukcesorem natomiast druga trasa jest dostępna lecz przez protokół EIGRP nie wykorzystywana.

Wydając polecenie uzyskamy szereg istotnych informacji z punktu widzenia protokołu EIGRP, a co najważniejsze poznamy składowe (w rozbiciu na trasę) dzięki którym algorytm DUAL przeprowadza swoje obliczenia.

1 - odległość ogłaszana,

2 - szerokość pasma,

3 - suma opóźnień,

4 - niezawodność,

5 - obciążenie,

6 - MTU,

7 - liczba skoków (routerów) jakie należy przejść by osiągnąć sieć.

Podsumowanie wszystkich tras wraz z informacją o dopuszczalnej odległości (FD) i ogłaszanej odległości (RD) poznamy po wydaniu polecenia: show ip eigrp topology all-links

Uzbrojeni w tą wiedzę przyjrzyjmy się jeszcze raz w jaki sposób zostaje wybrany dopuszczalny sukcesor lecz w tym przypadku (zdradzę na wstępie) warunek dopuszczalności zostaje spełniony.

Przyjrzyjmy się trasą prowadzącym do sieci 192.168.1.0/30 z punktu widzenia routera R1.

Już po wydaniu tego polecenia widać, że do docelowej sieci prowadzą dwie trasy. Pierwsza z nich poprzez router R2 jest sukcesorem natomiast druga poprzez router R3 dopuszczalnym sukcesorem (FD>RD - 3523840>3011840).

Sprawdźmy dalej i próbujmy sami obliczyć wartości dopuszczalnej odległości oraz ogłaszanej odległości.

Aby wykonać obliczenia skorzystajmy z polecenia: show ip eigrp topology 192.168.1.0/30

Dla trasy do sieci docelowej router R2 jest sukcesorem (IP 192.168.0.2 - interfejs s0/1 routera R2 - pkt. 1) natomiast router R3 dopuszczalnym sukcesorem ( IP 192.168.2.2 - interfejs s0/1 routera R3).

Przyjrzyjmy się trasie prowadzącej przez router R2 (sukcesor).

Trasa z najwolniejszym łączem to trasa pomiędzy routerami R2 a R3 - BW 1024 kb/s (pkt. 2) co po uwzględnieniu referencyjnej szerokości pasma da nam wartość: 10000000/1024= 9765

Kolejnym etapem jest wykonanie sumowania wszystkich opóźnień:

• • • trasa pomiędzy routerem R1 a R2 - DLY 20000 mikrosekund (łącze serialowe),
    • trasa pomiędzy routerem R2 a R3 - DLY 20000 mikrosekund (łącze serialowe),

Tak więc suma opóźnień = 20000+20000=40000 mikrosekund (pkt. 3)

Wynik ten dzielimy przez 10 ponieważ do wzoru należy podstawić wartość wyrażoną w dziesiątkach mikrosekund.

suma opóźnień = 40000/10=4000 jednostka: 10 mikrosekund

Wykonaliśmy wszystkie niezbędne przekształcenia wartości możemy podstawiać do wzoru:

gdzie:

K1 = 1; K3 = 1

Metryka została obliczona i jest zgodna z tą wyznaczoną przez router R1 (pkt. 4).

Zobaczmy teraz jak została obliczona odległość ogłaszana przez router R3 (dopuszczalny sukcesor) – metryka do sieci jest wyliczana z jego punktu widzenia.

Trasa z najwolniejszym łączem to trasa pomiędzy routerami R3 a R2 - BW 1024 kb/s co po uwzględnieniu referencyjnej szerokości pasma da nam wartość: 10000000/1024= 9765

Kolejnym etapem jest wykonanie sumowania wszystkich opóźnień (tylko jedna trasa):

• • • trasa pomiędzy routerem R3 a R2 - DLY 20000 mikrosekund (łącze serialowe),

Tak więc opóźnienie wynosi 20000 mikrosekund

Wynik ten dzielimy przez 10 ponieważ do wzoru należy podstawić wartość wyrażoną w dziesiątkach mikrosekund.

suma opóźnień = 20000/10=2000 jednostka: 10 mikrosekund

Wykonaliśmy wszystkie niezbędne przekształcenia wartości możemy podstawiać do wzoru:

gdzie:

K1 = 1; K3 = 1

Metryka została obliczona i jest zgodna z tą otrzymaną od routera R3 (pkt. 5).

Warunek dopuszczalności został sprawdzony tak więc trasa prowadząca poprzez router R3 staje się trasą z dopuszczalnym sukcesorem.

warunek dopuszczalności = FD (router R1) > RD (informacja od sąsiada R3)

warunek dopuszczalności = 3523840 > 3011840

Po przedstawieniu tych wszystkich przykładów mam nadzieję, że pojęcia sukcesor, dopuszczalny sukcesor i warunek dopuszczalności już Ci Czytelniku nie będą sprawiały problemu. Tak naprawdę, temat jeszcze nie jest zamknięty bo wracając do przykładu z siecią 10.0.0.0/24 w którym to warunek dopuszczalności nie został spełniony można postawić pytanie - Czy istnieje taki sposób aby trasa prowadząca przez router R3 spełniła warunek dopuszczalności? Części z Was pewnie już rozwiązania chodzą po głowie, sprawdźmy więc czy są zgodne z tymi, które zaprezentuję Ja.

Sposobów na zmianę metryki jest kilka, najpierw przedstawię możliwe rozwiązania a następnie spróbujemy je zastosować w praktyce, oczywiście wszystkie w odniesieniu do przykładu z siecią 10.0.0.0/24.

Dostępne metody zmiany metryki to:

• • • zmiana szerokości pasma interfejsu,
    • zmiana opóźnienia interfejsu,
    • zmiana wzoru służącego do wyliczenia metryki poprzez modyfikację parametrów K,
    • wykorzystanie list offsetowych.

Pierwszym ze sposobów wpływu na metrykę jest zmiana szerokości pasma interfejsu, przy czym zmiana tej wartości nie wpływa na fizyczną zmianę prędkości interfejsu. Wprowadzone zmiany powodują podstawienie zdefiniowanych przez nas wartości do wzorów odpowiedzialnych za wyliczenie dopuszczalnej odległości oraz odległości ogłaszanej. Z przykładu powyżej wiemy, że trasa prowadząca z punktu widzenia routera R1 do sieci 10.0.0.0/24 poprzez router R3 nie spełniła warunku dopuszczalności i router R3 nie jest dopuszczalnym sukcesorem dla tej sieci. Trasa posiada tylko sukcesora w postaci routera R2.

Spróbujmy ten stan zmienić, naszym celem jest taka zmiana pasma pomiędzy routerami R3 a R2 aby router R3 stał się dopuszczalnym sukcesorem. Czemu akurat ta trasa? Ponieważ router R3 przekazuje wartość RD routerowi R1 z swojego punktu widzenia (dla routera R3 jest to wartość FD). Zmiana szerokości pasma pomiędzy routerem R1 a R3 nic nam nie da.

Zmianę tę dokonujemy za pomocą polecenia: bandwidth <szerokość_pasma>. Polecenie wydajemy w trybie konfiguracji interfejsu i wartość pasma podawana jest w kb/s.

W naszej topologii prędkość pomiędzy routerami (R3-R2)została ustalona na 1024 kb/s spróbujmy tę wartość podwoić. Szerokość pasma została zmieniona na interfejsach obu routerów.

Po wprowadzeniu zmian sprawdźmy czy trasa prowadząca przez router R3 spełnia warunek dopuszczalności.

Jak widać powyżej wprowadzone zmiany w szerokości pasma pomiędzy routerami R3 a R2 zaowocowały zmianą obliczanych odległości co w konsekwencji doprowadziło do spełnienia przez router R3 warunku dopuszczalności (FD>RD - 2172416>1787392). Router R3 dla routera R1 odnośnie trasy 10.0.0.0/24 stał się dopuszczalnym sukcesorem.

Informację o zdefiniowanej szerokości pasma na danym interfejsie uzyskamy po wydaniu polecenia: show interfaces <nazwa_interfejsu>

Aby przywrócić domyślne wartości pasma należy użyć polecenia: no bandwidth.

Drugim sposobem na manipulację wyliczaną metryką jest zmiana opóźnień na interfejsach. I tak jak w przypadku powyżej zmianę tę będziemy dokonywać na łączu pomiędzy routerem R3 a R2. Wartość odległości RD przekazana przez router R3 wynosi 3037440, sprawdźmy jak zmieni się odległość ogłaszana gdy domyślną wartość interfejsu serialowego wynoszącą 20000 μs zmienimy na domyślną wartość interfejsu standardu GigabitEthernet czyli 10 μs.

Zmianę wartości opóźnienia dokonujemy za pomocą polecenia: delay <wartość_10_mikrosekund> wydanego w trybie konfiguracji interfejsu. Polecenie show interfaces <nazwa_interfejsu> wartość opóźnienia podaje w mikrosekundach natomiast w poleceniu: delay jednostką są dziesiątki mikrosekund. Wartości dopuszczalne zawierają się w zakresie od 1 do 16777215. Tak więc chcąc interfejsowi s0/0 routera R3 przypisać wartość 10 μs w poleceniu delay należy użyć 1.

Po wprowadzeniu zmian sprawdźmy opóźnienie interfejsu

Jak widać wartość opóźnienia uległa zmianie i wynosi teraz 10 μs, sprawdźmy jak przeprowadzona konfiguracja wpłynęła na zmianę wartości odległości ogłaszanej przez router R3.

Po porównaniu wartości FD i RD (2172416>2525696) dochodzimy do wniosku, że router R3 nadal nie spełnia warunku dopuszczalności i dlatego nie może być dopuszczalnym sukcesorem dla routera R1 odnośnie sieci 10.0.0.0/24

Trasie pomiędzy routerami R3 a R2 przypisaliśmy najmniejszą wartość opóźnienia na jaką pozwala system IOS, pomimo naszego wysiłku nie udało się doprowadzić do sytuacji w której router R3 jest dopuszczalnym sukcesorem (na razie).

Wydaje się, że ponieśliśmy klęskę choć jest jeszcze jedna rzecz na którą mamy wpływ a mianowicie możemy spowodować zwiększenie wartości FD wyliczanej przez router R1 tak by wartość ta była wyższa od wartości RD ogłaszanej przez router R3. Zmianę tę dokonamy oczywiście poprzez zmianę wartości opóźnienia pomiędzy routerami R1 a R2. Wartość opóźnienia podnosimy dwukrotnie.

Po zmianie opóźnień tablica topologii EIGRP przedstawia się następująco.

Porównując wartości FD oraz RD (2707456>2525696), router R3 staje się dopuszczalnym sukcesorem dla trasy 10.0.0.0/24.

Kolejnym sposobem manipulacji metryką jest zmiana wartości K tak aby uwzględnić dodatkowe parametry łącza. Niestety jakakolwiek zmiana składowych metryk powoduje zerwanie relacji sąsiedzkich gdyż wartości te w danym procesie EIGRP musza być ze sobą zgodne (ta sama konfiguracja na wszystkich routerach) w przeciwnym przypadku dostaniemy informację o niezgodności (tak jak poniżej).Relacja pomiędzy routerami został zerwane z powodu niezgodności składowych metryki EIGRP (K-value mismatch).

Tak więc jeśli przeprowadzamy zmianę składowych metryk musimy zmianę tą wykonać na wszystkich routerach biorących udział w danym procesie EIGRP. Manipulacja składowymi metryki jest procesem nieefektywnym choć oczywiście nic nie stoi na przeszkodzie by taką konfigurację przeprowadzić. Trochę musimy zmienić zasady, bo niestety tego sposobu nie da się użyć aby osiągnąć nasz cel (router R3 ma być dopuszczalnym sukcesorem) ponieważ zmiana wartości K pociąga taką samą zmianę na innych routerach co w konsekwencji prowadzi do zachowania stanu tablicy routingu choć oczywiście z innymi wartościami FD i RD. Naszym nowym zadaniem będzie uwzględnienie trasy prowadzącej przez router R3 jako drogi głównej do sieci 10.0.0.0/24 Zadanie to z logicznego punktu widzenia dość bezcelowe (by nie powiedzieć bezsensowne) bo po co ruch sieciowy kierować poprzez łącza o gorszych parametrach lecz przyjmijmy te nasze rozważania jako czysto akademickie i teoretyczne (możliwość jest lecz rodzi się pytanie po co?). Aby osiągnąć nasz cel musimy uruchomić odrębny proces EIGRP i spowodować by wartości wyliczone prze ten proces okazały się korzystniejsze od wartości procesu prowadzonego aktualnie.

Nowy proces EIGRP (proces aktualny używa numeru 1 my włączymy dodatkowy o numerze 2) uruchamiamy na wszystkich routerach a następnie ogłaszamy wszystkie sieci (polecenie: network) na trasie R1-R3-R2 (sieci 192.168.2.0/30; 192.168.1.0/30 uraz 10.0.0.0/24).

Poniżej zrzuty konfiguracji na wszystkich trzech routerach.

W kolejnym kroku przechodzimy do zmiany składowych metryki. Zmianę domyślnych składowych metryki przeprowadzamy w trybie konfiguracji procesu EIGRP za pomocą polecenia: metric weights <tos> <K1> <K2> <K3> <K4> <K5> Wartość tos (ang. type of service) zawsze jest równa 0.

Aby sprawdzić zdefiniowane wartości K należy posłużyć się poleceniem: show ip protocols

Po wprowadzonych zmianach możemy sprawdzić osiągnięte rezultaty. Po wydaniu polecenia: show ip eigrp topology all-links mamy wgląd we wpisy wszystkich tras obsługiwanych przez protokół EIGRP (jego dwie instancje). Dane są rozbite w odniesieniu do prowadzonego procesu. Analizując wyniki polecenia stwierdzamy, iż trasa prowadząca do sieci 10.0.0.0/24 z procesu EIGRP 1 jest niedostępna (ang. inaccessible) a jej rolę przejęła trasa z procesu EIGRP 2 jako ta z korzystniejszą metryką (EIGRP 1 - metryka: 2195456, EIGRP 2 - metryka: 82531)

Tablica routingu tylko potwierdza nasze obserwacje.

Tak więc osiągnęliśmy nasz cel, choć tak jak napisałem wcześniej przykład ten należy traktować w kategoriach czysto teoretycznych.

Ostatnią wspomnianą przeze mnie metodą jest skorzystanie z tzw. list offsetowych. Listy te pozwalają nam na dodanie do obliczonej dla danej trasy przez router metryki stałej wartości zdefiniowanej przez administratora. Po skonfigurowaniu listy do metryki będzie dodawane przesunięcie.

Lista offsetowa pozwala nam na:

• • • zastosowanie przesunięcia odnośnie określonych prefiksów i masek (dopasowanie następuje na podstawie wcześniej zdefiniowanej listy ACL),
    • określenie kierunku aktualizacji (wysyłanie bądź odbieranie),
    • określenie interfejsu z którego jest prowadzona aktualizacja,
    • określenie wartości przesunięcia.

A więc jak już wiemy czym jest i na co pozwala lista offsetowa przejdźmy do naszego zadania. Przed założeniem listy musimy się zastanowić: na którym routerze, interfejsie i odnośnie której sieci zastosować przesunięcie (no i oczywiście o jaką wartość). Naszym celem jest by router R3 stał się sukcesorem dopuszczalnym tak więc wartość RD ogłaszana przez ten router musi być mniejsza od wartości FD obliczonej przez router R1 (wartości te aktualnie wynoszą: FD 2195456, RD 3037440). Zdefiniowane przesunięcie może być tylko dodatnie tak więc musimy spowodować zwiększenie wartości FD tak aby warunek dopuszczalności mógł zostać spełniony.

Różnica pomiędzy wartościami wynosi: 3037440-2195456=841984 czyli aby warunek dopuszczalności mógł zostać spełniony minimalne przesunięcie musi wynieść 841985

W sposobie tym kolejny raz została użyta lista ACL, której zadaniem jest określenie sieci co do której będzie stosowane przesunięcie (pkt. 1) - prosta lista ACL o numerze 1 odnosząca się do sieci 10.0.0.0/24 W kolejnym kroku (pkt.2) przechodzimy do konfiguracji procesu routingu w którym to za pomocą polecenia: offset-list <numer_listy_ACL> <kierunek> <wartość_przesunięcia> <interfejs> określamy przesunięcie metryki o zdefiniowaną wartość (pkt. 3).

Po wprowadzeniu zmian warunek dopuszczalności jest spełniony - FD 3037441 > RD 3037440 i router R3 dla sieci 10.0.0.0/24 jest dopuszczalnym sukcesorem.

Informację o zdefiniowanym przesunięciu uzyskamy po wydaniu polecenia: show ip protocols

Nasze zadanie moglibyśmy również wykonać w inny sposób a mianowicie zamiast dodawać offset na interfejsie s0/1 routera R1 możemy spowodować aby to router R2 wartość tą dodawał do swoich pakietów aktualizacji.

Gdy już omówiliśmy sobie aspekty związane z metryką przyszedł czas aby zająć się problemami związanymi z redystrybucją tras (trasa domyślna, trasy statyczne czy te pozyskane z innych protokołów routingu) a także z sposobami ich filtrowania. Zahaczymy również o temat związany z sumaryzacją tras tak aby zmniejszyć liczbę wpisów w tablicy routingu.

Zaczniemy od omówienia redystrybucji trasy domyślnej. Trasa ta jest trasą statyczną pasującą do każdego z adresu IP (0.0.0.0/0). Trasę tę najczęściej wykorzystuje się do przekazania ruchu sieciowego poza domenę prowadzonego routingu EIGRP (trasa ta nie jest zarezerwowana tylko dla EIGRP, rozwiązanie te jest również wykorzystywane przy innych protokołach routingu jak RIP czy OSPF) czyli rozwiązanie te świetnie nadaje się aby trasę tą skonfigurować na routerze, który jest bezpośrednio połączony z naszym usługodawcą internetowym, tak aby w naszej sieci była możliwość prowadzenia komunikacji z światem zewnętrznym (Internet).

Tak więc aby omówić te zagadnienie musimy lekko zmodyfikować naszą ćwiczebną topologię i dodać do niej router symulujący nam ISP (IP 213.213.213.213)

Trasę zerową i jej redystrybucję będziemy konfigurować na routerze R2 ponieważ to ten router łączy się z ISP.

Trasę 0.0.0.0/0 konfigurujemy w ten sam sposób jak każdą inną trasę statyczną.

Po konfiguracji trasy możemy efekt naszych działań sprawdzić w tablicy routingu.

Trasa zerowa jest uwzględniona w tablicy routingu routera R2 tak więc naszym kolejnym zadaniem jest rozpropagowanie tej informacji do innych routerów (R1 oraz R3).

Redystrybucję trasy przeprowadzimy za pomocą polecenia: redistribute static wydanym w trybie konfiguracji routingu.

Po wydaniu polecenia możemy sprawdzić czy informacja o trasie zerowej została przekazana innym routerom. Sprawdźmy router R3.

Wszystko przebiegło według naszych oczekiwań, informacja została rozpropagowana prawidłowo i w tablicy routera R3 znajduje się wpis dotyczący trasy 0.0.0.0/0 (jak widać trasa ta jest zewnętrzną trasą EIGRP) a dodatkowo sprawdzenie trasy nastąpiło poprzez wysłanie pakietów ICPM na adres routera ISP.

Informację o trasie tej oczywiście również uzyskamy po wydaniu polecenia: show ip eigrp topology

Przy redystrybucji trasy zerowej 0.0.0.0/0 akceptowalne jest rozgłoszenie tej sieci za pomocą polecenia: network 0.0.0.0 zamiast stosowania komendy: redistribute static - jest to przypadek szczególny, choć zazwyczaj stosuje się propagacje trasy za pomocą trasy statycznej.

Po wydaniu polecenia oprócz informacji o trasie 0.0.0.0/0 zostaje rozpropagowana powiązana z nią poleceniem definicji trasy statycznej sieć pomiędzy routerem R2 a ISP. Droga do sieci 0.0.0.0/0 nie jest już ogłaszana jako trasa zewnętrzna.

Innym sposobem (rzadziej używanym) przekazania informacji o trasie domyślnej jest skorzystanie z polecenia: ip default-network <adres_sieci> Sposób ten polega na oznakowaniu trasy do sieci, która po rozpropagowaniu będzie uważana przez inne routery jako trasa domyślna.

Wracając do naszej zmienionej topologii z ISP należałoby za pomocą polecenia network sieć tą rozgłosić w naszej domenie routingu EIGRP. Niestety nie możemy tego wykonać ponieważ sieć ta nie spełnia warunku klasowości. Wymagane jest aby rozgłaszana sieć należała do klasy A, B lub C. Nie zostało to zaznaczone na rysunku powyżej ale sieć pomiędzy routerem R2 a ISP jest z definiowana z prefiksem /30. Aby ominąć ten warunek można na routerze R2 odpowiedzialnym za wygenerowanie trasy domyślnej zdefiniować interfejs pętli zwrotnej z prefiksem, który będzie spełniał narzucany warunek klasowości.

Na listeningu poniżej zdefiniowano:

1 - interfejs pętli zwrotnej loopback 1,

2 - interfejsowi loopback 1 przypisano adres IP 192.168.10. 1 należący do sieci klasy C,

3 - sieć 192.168.10. 0/24 ogłoszono w procesie EIGRP.

Po ogłoszeniu sieci, sieć tę należy zdefiniować jako sieć domyślną - polecenie: ip default-network 192.168.10.0

Po wydaniu polecenia określającego sieć domyślną, router R2 sieć 192.168.10.0/24 oznakuje ją jako kandydatkę na trasę domyślną. Z powodu braku innych kandydatów sieć ta faktycznie staje się trasą domyślną. Na rysunku poniżej przedstawiono tablice routingu routera R3 w której to sieć 192.168.10.0/24 jest siecią domyślną (sieć ta oznaczona jest gwiazdką). W przypadku istnienia wielu kandydatów brane jest pod uwagę w pierwszej kolejności - odległość administracyjna ogłaszanej sieci a następnie jej metryka.

Z rysunku powyżej można wysnuć jeszcze jeden wniosek, a mianowicie, że router R3 nie zna trasy do sieci 213.213.213.212/30 a pomimo tego łączność z tą siecią jest zapewniona.

Komunikacja ta jest zapewniona dzięki ustawieniu wpisu bramy ostatniej szansy (ang. gateway of last resort) w tablicy routingu.

Co wymaga podkreślenia, router na którym zostało skonfigurowane polecenie definiujące sieć domyślną nie używa tej trasy jako domyślnej w przeciwieństwie do przykładu z redystrybucją trasy statycznej (rysunki poniżej - pierwszy - sieć domyślna, drugi - trasa statyczna).

Informację o zdefiniowanej trasie domyślnej znajdziemy również po wydaniu polecenia: show ip eigrp topology - wpis exterior flag is set

Ogłaszanie trasy domyślnej zostało omówiona a więc powróćmy jeszcze na chwilę do tras statycznych aby omówić trochę bardziej zaawansowane metody propagacji informacji o nich a następnie przejdziemy do omówienia tras dynamicznych. Omówię również sposoby filtrowania tych tras tak aby do sąsiadów trafiła informacja o trasach, które faktycznie chcemy ogłosić.

Polecenie redistribute static nie tylko jest używane do tego by rozpropagować informację o trasie domyślnej lecz również o każdej innej trasie statycznej. Aby omówić to zagadnienie zmienimy trochę nasza topologię.

Został dodany router R4 na którym to zdefiniowano trzy interfejsy pętli zwrotnej.

Do sieci reprezentowanych poprzez interfejsy loopback na routerze R2 zostały zdefiniowane trasy statyczne.

Trasy statyczne rozpropagujemy za pomocą znanego nam już polecenia: redistribute static Po sprawdzeniu sąsiedniego routera stwierdzamy, że trasy te faktycznie zostały ogłoszone.

Warto jeszcze dopowiedzieć, że mamy wpływ na metrykę ogłaszanych tras. Wystarczy, że w wydanym poleceniu redistribute static zdefiniujemy parametry odpowiedzialne za jej wyliczenie tj. redistribute static metric <szerokość_pasma> <opóźnienie> <dostępność> <pasmo_efektywne> <MTU> (podobnie jak w poleceniu set metric przykład z redystrybucją trasy połączonej bezpośrednio).

Poniżej przykład zmiany metryki po wydaniu na routerze R2 polecenia: redistribute static metric 128 100 255 1 1500

Trasy zostały ogłoszone, ale pojawia się pytanie - Co zrobić aby ogłosić trasy tylko te, które faktycznie chcemy przekazać swoim sąsiadom? Proces ten nazywany jest filtrowaniem tras i pozwala administratorowi wybrać te trasy, które mają być ogłoszone z pominięciem tras nieistotnych. Do dyspozycji mamy trzy rozwiązania:

• • • użycie listy dystrybucyjnej w połączeniu z listą kontroli dostępu ACL,
    • lista prefiksów,
    • mapa tras.

Wszystkie trzy sposoby postaram się omówić choć z innymi sposobami pozyskania informacji o trasach. Zaczniemy od pierwszego sposobu czyli do filtrowania tras użyjemy listy dystrybucyjnej.

Koncepcja użycia listy dystrybucyjnej polega na utworzeniu listy ACL (tak jak w przypadku ogłaszania trasy bezpośrednio połączonej), która będzie odpowiedzialna za zezwalanie bądź zabranianie ogłaszania danej sieci. Tak więc sieć z klauzulą permit będzie ogłaszana a ta z klauzulą denny blokowana. Lista ACL następnie jest łączona z listą dystrybucyjną, która jest odpowiedzialna za definicję kierunku blokowania (in lub out) i interfejsu, na którym ma nastąpić filtracja. Z listą dystrybucyjną możemy łączyć zarówno standardowe listy ACL jak i nazwane.

Naszym zadaniem jest rozgłoszenie w domenie routingu EIGRP tylko sieci 10.0.10.0/24. W pierwszej kolejności zostaje utworzona lista ACL o numerze 5 w której to zezwolono na przekazanie informacji o sieci 10.0.10.0/24 (pkt. 1). Następnie w konfiguracji procesu routingu (pkt. 2) połączono wcześniej utworzoną listę ACL z listą dystrybucyjną (pkt. 3). Kierunek filtracji został określony jako wyjście. Brak zdefiniowanego interfejsu powoduje, że lista ta zostaje założona na wszystkie interfejsy routera.

Ktoś dociekliwy (lecz nie obeznany z listami ACL) mógłby zapytać - Dlaczego w konfiguracji listy ACL nie pojawiły się zapisy denny przy sieciach 10.0.11.0/24 oraz 10.0.12.0/24? Stało się tak ponieważ na końcu każdej listy ACL zostaje dołączony zapis zabraniający na jakikolwiek nie zdefiniowanyt ruch sieciowy. Sieć 10.0.10.0/24 została zapisana z klauzulą permit dlatego jest ogłaszana, domyślna klauzula deny blokuje sieci pozostałe. Dla osób mający pierwszy kontakt z listami ACL dopowiem, że kolejność dokonywanych wpisów ma znaczenie gdyż np. gdy wydamy w pierwszej kolejności wpis zabraniający, to pomimo późniejszego dodania wpisu zezwalającego nie zostanie on uwzględniony (o listach ACL napiszę więcej już wkrótce).

Nasze zadanie moglibyśmy również wykonać poprzez założenie listy wejściowej na routerze R1 oraz R3.

Po wybraniu jednego z dwóch sposobów efekt jest ten sam w tablicy routingu istnieje tylko trasa do sieci 10.0.10.0/24

Można by zapytać - Który sposób wybrać? Z punktu działania sieci i jej szybkości lepiej wybrać sposób pierwszy, gdyż po co generować ruch sieciowy i przesyłać go dalej kiedy i tak będzie on zablokowany.

Pozostańmy chwilkę jeszcze przy tym przykładzie, gdyż tą samą topologię wykorzystamy do omówienia ręcznego podsumowania sieci. W przykładzie opcja automatycznego podsumowania na granicach sieci została wyłączona (polecenie: no auto-summary) ale nie wyklucza to włączenia ręcznego podsumowania. Podsumowywać będziemy sieci zdefiniowane poprzez interfejsy loopback na routerze R4. Dążymy do tego aby w tablicach routingu sąsiadów zamiast trzech odrębnych wpisów prowadzących do tych sieci znajdował się jeden.

Na routerze R2 i R4 do prowadzonego procesu EIGRP zostały dodane nowe sieci:

• • • router R2 - sieć 192.168.3.0/24
    • router R4 - sieci: 192.168.3.0/24, 10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24,

Trasy do tych sieci znajdują się w tablicach routingu sąsiadów (router R3)

Interesujące nas sieci za pomocą polecenia: network zostały ogłoszone w procesie routingu EIGRP teraz postaramy się je podsumować lecz za nim to zrobimy musimy wyliczyć sieć sumaryzacyjną interesujące nas sieci.

Wyliczenie przeprowadzamy poprzez rozpisanie binarnie sieci i określenie maksymalnego dopasowania (granicy podsumowania). Dopasowanie następuje do 21 bitu włącznie jest to granica podsumowania. W kolejnym kroku do 32 bitu dopełniamy zerami i wykonujemy przeliczenie z systemu dwójkowego na dziesiętny czego efektem jest sieć: 10.0.8.0/21 (trochę dokładniejszy opis sumaryzacji znajdziesz tu: Co w sieci siedzi. Routing statyczny)

Wyliczyliśmy sieć podsumowującą sieci: 10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24, a więc przeprowadźmy podsumowanie. Podsumowanie wykonujemy w trybie konfiguracji interfejsu za pomocą polecenia: ip summary-address eigrp <nr_procesu> <adres_sieciowy> <maska_podsieci> Router R4 jest z sąsiadami połączony za pomocą interfejsu s0/0 tak więc podsumowanie będzie przeprowadzone na tym interfejsie.

Po wykonaniu ręcznego podsumowania sprawdźmy efekt naszych działań na routerach sąsiednich. W tablicy routingu routera R3 zamiast trzech wpisów teraz znajduje się jeden reprezentujący zsumaryzowane sieci.

Aby mieć 100% pewność sprawdźmy jeszcze łączność z każdym z interfejsów loopback. Łączność jest zapewniona nasz cel został osiągnięty.

Informację na temat zastosowanej sumaryzacji wraz z listą interfejsów rozpowszechniających uaktualnienia znajdziemy po wydaniu polecenia: show ip protocols

Gdy zachodzi potrzeba, uogólnienie tras możemy wykonać jednocześnie dla kilku różnych adresów sieci. Oznacza to, że na danym interfejsie proces sumaryzacji może być wykonany kilkukrotnie.

Redystrybucja tras statycznych oraz sumaryzacja zostały omówione. Czas zająć się redystrybucją tras pochodzących od innych protokołów routingu dynamicznego.

Topologia pozostaje bez zmian. Natomiast zmienił się sposób pozyskania informacji o sieciach dostępnych dzięki routerowi R4. Pomiędzy routerami R2 a R4 działa protokół RIPv2. Na tym etapie tylko router R2 zna trasy do sieci za routerem R4.

Tablica routingu routera R2

Tablica routingu routera R3

Aby rozpropagować trasy pozyskane od innego protokołu routingu dynamicznego należy skorzystać z komendy: redistribute <nazwa_protokołu> <opcje_dodatkowe> (pkt. 2) Polecenie wydajemy w trybie konfiguracji routingu (pkt. 1) Po zdefiniowaniu redystrybucji należy określić parametry według których zostanie wyliczona metryka EIGRP (pkt. 3) Parametry metryki definiujemy w taki sam sposób jak w przykładach przedstawionych wcześniej.

W przykładzie zostało użyte polecenie: default-metric, które definiuje składowe metryki dla wszystkich zewnętrznych protokołów routingu. Gdyby zachodziła taka potrzeba to dla każdego z użytych protokołów routingu dynamicznego składowe te można określić osobno np. dla protokołu RIP: redistribute rip metric 1000 100 255 1 1500 czy dla OSPF: redistribute ospf <numer_obszaru> metric 1000 100 255 1 1500

Po włączeniu ogłaszania sieci uzyskanych dzięki protokołowi RIP od routera R4 sprawdźmy czy informacje te zostały przekazane sąsiadom. W tablicy routingu routera R3 trasy do sieci są uwzględnione.

I tu tak samo jak w przypadku sieci statycznych nasuwa się pytanie - Co zrobić w przypadku, w którym to chcemy ogłosić tylko część sieci? Pierwszy sposób już przedstawiłem czas by omówić kolejny a mianowicie wykorzystanie list prefiksów. Naszym zadaniem tak jak w przykładzie poprzednim będzie jedynie rozgłoszenie sieci 10.0.10.0/24 z pominięciem pozostałych.

Do konfiguracji filtrowania adresów użyjemy polecenia: ip prefix-list, zainicjowany dzięki temu poleceniu mechanizm pozwala nam na analizowanie długości zdefiniowanej maski sieci jak i samej maski. Polecenie te w połączeniu z poznaną wcześniej komendą: distribute-list ma możliwość ustawienia dwóch stanów działania: zezwolenia bądź odmowy dla każdego pasującego prefiksu/długości.

Ogólna składnia polecenia jest następująca: ip prefix-list <nazw_listy> <wartość_sekwencyjna> <stan: deny lub permit> <sieć_maska> <wartość_ge> <wartość_le>

By zrozumieć sposób działania listy prefiksów najpierw zaczniemy od omówienia składowych polecenia a następnie parę przykładów by na końcu przejść do konfiguracji routerów w naszej przykładowej topologii.

<nazw_listy> - nazwa tworzonej listy,

<wartość_sekwencyjna> - lista prefiksów może składać się z kliku wpisów a zadaniem numeru sekwencyjnego jest ustalenie kolejności przetwarzania listy. Oznacza to, że mamy możliwość definicji kolejności przeprowadzanych działań, dodatkowo numer sekwencyjny przydatny jest w późniejszej edycji samej listy gdyż w przypadku wystąpienia zmian nie musimy kasować całej listy a tylko wpis do którego zmiana się odnosi,

<stan: deny lub permit> - deny - zabronienie, permit - zezwolenie,

<sieć_maska> - adres IP sieci wraz z maską, do której polecenie ip prefix-list ma zastosowanie,

<wartość_ge> - parametr opcjonalny, oznaczający większy bądź równy (ang. greater than or equal to),

<wartość_le> - parametr opcjonalny, oznaczający mniejszy bądź równy (ang. less than or equal to).

Tak więc mamy możliwość utworzenia czterech wariancji polecenia: ip prefix-list gdyż część składowych polecenia jest opcjonalna. Po krótce omówienie tych czterech przypadków poniżej.

Opcja 1: polecenie przyjmuje postać: ip prefix-list <nazw_listy> <wartość_sekwencyjna> deny 192.168.0.0/24 - brak definicji parametrów ge oraz le - oznacza to, że zdefiniowana lista będzie miała tylko zastosowanie dla trasy 192.168.0.0/24,

Opcja 2: polecenie przyjmuje postać: ip prefix-list <nazw_listy> <wartość_sekwencyjna> deny 192.168.0.0/6 ge 10 le 15 - oba parametry ge oraz le zostały zdefiniowane - oznacza to, że zdefiniowana lista będzie pasować do tras których długość prefiksów mieści się w przedziale od 10 do 15 włącznie - sieci: 192.168.0.0/10, 192.168.0.0/11, 192.168.0.0/12, 192.168.0.0/13, 192.168.0.0/14, 192.168.0.0/15,

Opcja3: polecenie przyjmuje postać: ip prefix-list <nazw_listy> <wartość_sekwencyjna> deny 192.168.0.0/6 ge 10 - został zdefiniowany tylko parametr ge - oznacza to, że zdefiniowana lista będzie pasować do tras których długość prefiksów mieści się w przedziale od 10 do 32 włącznie czyli sieci od 192.168.0.0/10 do 192.168.0.0/32,

Opcja 4: polecenie przyjmuje postać: ip prefix-list <nazw_listy> <wartość_sekwencyjna> deny 192.168.0.0/6 le 12 - został zdefiniowany tylko parametr le - oznacza to, że zdefiniowana lista będzie pasować do tras których długość prefiksów mieści się w przedziale od 6 do 12 włącznie czyli sieci od 192.168.0.0/6 do 192.168.0.0/12.

Osobne wytłumaczenie należy się dwóm szczególnym przypadkom a więc gdy lista prefiksów została skonfigurowana z adresem sieci 0.0.0.0/0 oraz 0.0.0.0/0 le 32 W pierwszym przypadku zapis 0.0.0.0 oznacza „wszystkie adresy sieci” lecz ustawiona maska /0 wymusza ustawienie długości prefiksu na 0 tak więc lista z tak ustawionym adresem sieciowym nie będzie miała zastosowania do żadnej sieci prócz trasy domyślnej.

Zaś w drugim przypadku mamy sytuację odwrotną bo lista zdefiniowana w ten sposób będzie miała zastosowanie do wszystkich tras. Ponieważ adres sieci ustawiony na 0.0.0.0 będzie pasował do wszystkich adresów sieci zaś zapis le 32 powoduje, że zakres długości prefiksu (masek sieci) mieści się w przedziale od 0 do 32.

Kończąc temat list prefiksów i przechodząc do naszego przykładu należy wspomnieć by definiowana lista prefiksów nie została odrzucona musi ona spełnić następujący warunek:

długość prefiksu <= zdefiniowana wartość ge <= zdefiniowana wartość le

To wracamy do przykładu, dla przypomnienia naszym zadaniem jest rozpropagowanie tylko informacji o sieci 10.0.10.0/24 Ogłoszenie sieci 10.0.10.0/24 nastąpiło według listeningu poniżej.

1 - przechodzimy do trybu konfiguracji routingu EIGRP,

2 - w trybie konfiguracji routingu wydajemy polecenie: distribute-list prefix <nazwa_listy> <kierunek_blokowania> Naszym zadaniem jest zablokowanie redystrybucji tras do sieci 10.0.11.0/24 i 10.0.12.0/24 dlatego lepszym rozwiązaniem jest blokada na wyjściu (out) routera R2 gdyż ten router zna trasę do tych sieci i to on jest odpowiedzialny za ich rozgłaszanie. Oczywiście możliwe jest również zastosowanie parametru in lecz w takim przypadku konfiguracja powinna być przeprowadzona na każdym routerze na którym chcemy zastosować filtrację. Dobór kierunku filtrowania jest mocno zależny od topologii naszej sieci i tak naprawdę sami musi zdecydować jakie rozwiązanie będzie dla nas najlepsze. Nazwa listy dystrybucyjnej została zdefiniowana jako: filtr

3 - za pomocą listy prefiksów określamy sieci co do których lista będzie miała zastosowanie. Lista ta jest łączona z wcześniej zdefiniowaną listą dystrybucji (nazwa: filtr) dodatkowo określany jest numer sekwencyjny (5), stan (deny - zabroń) oraz sieć do której lista ma zastosowanie - w naszym przypadku lista zabrania przekazania informacji o sieci 10.0.11.0/24,

4 - wpis o numerze sekwencyjnym 15 zabraniający przekazanie informacji o sieci 10.0.12.0/24,

5 - wpis pozwalający na przekazanie informacji (stan permit) o wszystkich pozostałych sieciach. Gdyby tego wpisu zabrakło router nie przekazałby informacji o trasach prowadzących do innych sieci. Trzeba jawnie określić, że filtracji nie mają podlegać pozostałe trasy.

Po skonfigurowaniu listy prefiksów czas by zajrzeć do tablicy routingu sąsiada by stwierdzić czy nasza konfiguracja przyniosła pożądane efekty. Zajrzyjmy do tablicy routera R3.

Jak widać powyżej w tablicy routingu znajduje się jedynie wpis do sieci 10.0.10.0/24, sieci 10.0.11.0/24 i 10.0.12.0/24 nie są uwzględnione. Dodatkowo znalazła się informacja o sieci 192.168.3.0/30 (dzięki zapisowi: ip prefix-list filtr seq 20 permit 0.0.0.0/0 le 32)Tak więc mamy omówiony drugi sposób filtrowania sieci z wykorzystaniem listy prefiksów.

A więc nic nie stoi na przeszkodzie by przejść do trzeciego, ostatniego sposobu filtrowania tras. Tym razem skorzystamy z metody odwzorowania tras czyli tzw. mapy routingu. Ale by trochę urozmaicić przykład tym razem pomiędzy routerem R2 a R4 uruchomimy protokół routingu OSPF. Protokół został uruchomiony na routerze R2 w tablicy routingu znajdują się sieci, które ogłasza router R4.

Informację o sieciach 10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24 posiada na razie tylko router R2. By to zmienić rozgłośmy te sieci innym routerom. Rozgłoszenie następuje po wydaniu polecenia: redistribute ospf 1 (1 dlatego, że z takim numerem jest uruchomiony proces OSPF). Sieci uzyskane od protokołu OSPF zostają rozgłoszone z metryką, która zostaje obliczona dzięki parametrom określonym w poleceniu: default-metric (polecenie to musimy wydać by trasy mogły być ogłoszone).

Po rozgłoszeniu tras na routerze R2 sprawdźmy czy informacja ta dotarła do routerów R1 i R3. Poniżej tablica routingu routera R3 jak widać informacje o trasach uzyskane dzięki protokołowi OSPF zostały przekazane w aktualizacjach protokołu EIGRP (sieć pomiędzy routerami R2 i R4 czyli sieć 192.168.3.0/30 jest ogłaszana gdyż ona również bierze udział w procesie OSPF).

Naszym zadaniem będzie przekazanie informacji innym routerom o sieciach 10.0.10.0/24 oraz 10.0.11.0/24 a zablokowanie dystrybucji sieci 10.0.12.0/24 oraz 192.168.3.0/30. Tradycyjnie już operację wykonamy na routerze R2 gdyż to on jest odpowiedzialny za przekazanie tych informacji pozostałym routerom. Do filtracji tras wykorzystamy mechanizm odwzorowania tras. Sposób konfiguracji został pokazany na rysunku poniżej.

1 - lista ACL o numerze 5 zezwalająca na ruch do sieci 10.0.10.0/24,

2 - lista ACL o numerze 15 zezwalająca na ruch do sieci 10.0.11.0/24,

3 - mapa routingu o nazwie filtrospf z numerem sekwencyjnym 10 (kolejność z którą router będzie przetwarzał zdefiniowane reguły), klauzula permit określa czy operacje konfigurujące tą mapę mają zostać zastosowane,

4 - włączenie porównania nagłówka adresu IP z zdefiniowaną listą ACL o numerze 5,

5 - kolejna definicja (o numerze sekwencyjnym 20) dotycząca mapy routingu o nazwie filtrospf nakazujący wykonanie poleceń (klauzula: permit) zawartych w tym wpisie,

6 - włączenie porównania nagłówka adresu IP z zdefiniowaną listą ACL o numerze 15,

7 - definicja (o numerze sekwencyjnym 30) dotycząca mapy routingu o nazwie filtrospf zabraniająca przekazania pakietów nie spełniających powyższe zdefiniowane reguły,

8 - ogłoszenie sieci w domenie EIGRP uzyskanych dzięki protokołowi OSPF (numer procesu 1) z regułami zawartymi w mapie odwzorowania tras o nazwie filtrospf.

Po wykonaniu konfiguracji czas by zobaczyć efekt wykonanych operacji. Sprawdzamy tablicę routingu na routerze R3.

Nasz cel został osiągnięty w tablicy znajdują się tylko trasy do sieci zdefiniowane w mapie routingu z klauzulami permit. Test ping tylko potwierdza wykonanie zadania. Osiągalne są tylko sieci: 10.0.10.0/24 oraz 10.0.11.0/24

Mapa routingu i zawarte w niej polecenia pozwalają nam na znacznie więcej lecz tak jak już wspomniałem jest to temat na całkiem osobny wpis ale żeby zademonstrować możliwości odwzorowywania tras pokaże jeszcze jedno polecenie. Mapa trasy może być również użyta do zmiany ogłaszanej metryki, jak widać powyżej trasy do sieci są rozgłaszane z tą samą metryką wynoszącą: 3097600 gdybyśmy z jakiś powodów chcieli te wartości zmienić wystarczy dodać odpowiedni wpis do mapy a odnoszący się do danej sieci. Tak więc spróbujmy zmienić metrykę trasy prowadzącej do sieci 10.0.10.0/24

Za pomocą polecenia: set metric zdefiniowaliśmy wartości parametrów służących do obliczenia metryki EIGRP (wartości zdefiniowane w mapie routingu mają pierwszeństwo przed wartościami ustalonymi dzięki poleceniu: default-metric).

Sprawdźmy czy metryka odnośnie sieci 10.0.10.0/24 uległa zmianie.

Jak widać powyżej tak się właśnie stało. Obliczona metryka do sieci 10.0.10.0/24 używa wartości zdefiniowanych w poleceniu mapy routingu (została określona mniejsza wartość szerokości pasma) natomiast do obliczenia metryki do sieci 10.0.11.0/24 zostały użyte parametry metryki zdefiniowane w poleceniu: default-metric

Informacje o zdefiniowanym odwzorowaniu tras uzyskamy po wydaniu polecenia: show route-map <nazwa_odwzorowania>

Polecenie informuje nas o skonfigurowanych listach dostępu wraz z powiązaniem z konkretnymi wpisami mapy routingu. Dodatkowo mamy wgląd w statystyki dotyczące zastosowanej polityki routingu.

Powoli zbliżamy się do końca mam nadzieję, że po lekturze tego wpisu konfiguracja protokołu EIGRP nie sprawi Ci Czytelniku najmniejszych problemów. Jeśli zaś coś nie wychodzi to spróbuj rozwiązania poszukać przy wykorzystaniu przedstawionych już przeze mnie poleceń lub skorzystaj z tych przedstawionych poniżej.

Gdy coś nie gra najlepiej jest włączyć proces debugowania informacji protokołu EIGRP gdyż wtedy dokładnie jak na dłoni będziemy widzieli jakie router wykonuje operacje i jakie decyzje podejmuje.

Oprócz przedstawionego już polecenia: debug eigrp packet możesz wykorzystać komendę: debug eigrp fsm, która poinformuje się o działaniu algorytmu DUAL czyli jakie trasy są wpisywane bądź usuwane z tablicy routingu oraz jakie wartości odległości są wyliczane i otrzymywane przez router.

Natomiast polecenie: debug eigrp packets dostarczy nam bardzo dokładnych informacji na temat otrzymywanych i wysyłanych pakietów procesu EIGRP.

Do polecenia dodając nazwę pakietu spowodujemy wyświetlenie tylko informacji o wybranym pakiecie gdy np. chcemy uzyskać informację o pakietach Hello nasze polecenie przyjmie postać: debug eigrp packets hello gdy zaś interesują nas pakiety Update - debug eigrp packets update

Włączając proces debugownia komendą: debug eigrp neighbors uzyskamy informację o zmianie statusu nawiązywanych relacji sąsiedzkich z innymi routerami.

Do uzyskania informacji o tym co się dzieje z sąsiadem może nam posłużyć jeszcze jedno polecenie a mianowicie: eigrp log-neighbor-changes

Polecenie przydaje się gdy chcemy monitorować statusy sąsiadów a dodatkowo daje nam możliwość zapisu tych informacji do dziennika SYSLOG.

I tym radosnym akcentem chciałbym zakończyć ten wpis. Protokoły routingu te najważniejsze: RIP, OSPF i EIGRP zostały omówione następny art dotyczący routerów CISCO będzie dotyczył list kontroli dostępu czyli potocznie zwanych ACeLek.

 Bibliografia:

http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13669-1.html

http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13675-16.html

http://notthenetwork.me/blog/2013/06/19/ccnp-route-study-eigrp-passive-interfaces/

https://www.informit.com/library/content.aspx?b=CCIE_Practical_Studies_I&seqNum=123

http://study-ccna.com/administrative-distance-metric

http://networklessons.com/eigrp/how-to-configure-eigrp-authentication/

http://www.jordanmartin.net/2011/11/09/eigrp-authentication-with-keychains/

https://www.youtube.com/watch?v=rG8Qgp4bEKc