plik


ÿþBIULETYN INSTYTUTU AUTOMATYKI I ROBOTYKI NR 16, 2001 ProtokoBy rutingu dynamicznego Tomasz MALINOWSKI ZakBad Teleinformatyki, Instytut Automatyki i Robotyki WAT, ul Kaliskiego 2, 00-908 Warszawa. STRESZCZENIE: W artykule omówiony zostaB sposób implementacji i konfiguracji popularnych protokoBów rutingu z wykorzystaniem oprogramowania GNU Zebra. Zamieszczone zostaBy wskazówki dotyczce instalacji oprogramowania w systemie Linux oraz konfigurowania najcz[ciej wykorzystywanych, równie| w ruterach CISCO, protokoBów: RIP, OSPF i BGP. Zaprezentowana przykBadowa konfiguracja protokoBów stanowi wstp do budowy bardziej zBo|onych systemów. Omawiane oprogramowanie mo|e by podstaw budowy, niewielkim kosztem, zBo|onych konfiguracji ruterów, z ró|nymi zestawami protokoBów. Zdaniem autora [rodowisko laboratoryjne z programowymi ruterami, zachowujcymi funkcjonalno[ ruterów sprztowych stanowi cenny materiaB dydaktyczny. Podana charakterystyka wymienionych protokoBów stanowi wstp do studiowania zasad ich dziaBania i wykorzystania. 1. Wstp W artykule omawiane s aspekty realizacji rutingu dynamicznego w [rodowisku Linux (Unix). Zalet stosowania w roli ruterów hostów (tutaj komputerów klasy PC) jest niewielki koszt rozwizania oraz mo|liwo[ wykorzystania hosta do speBniania dodatkowych funkcji np. serwera plików. W przeciwieDstwie do ruterów pracujcych na hostach, rutery dedykowane s zoptymalizowane do przeBczania pakietów IP (zarzdzanie buforami w tych urzdzeniach, kontrola procesów i schematy obsBugi przerwaD zostaBy opracowane z my[l o jednym zadaniu, zadaniu wymiany tablic rutingu i dokonywania wyboru drogi w sieci dla napBywajcych do rutera pakietów). W poBczeniu z brakiem konieczno[ci obsBugi wielu u|ytkowników, kompilatorów i systemu plików posiadamy urzdzenie pracujce znacznie 51 T. Malinowski wydajniej. Niewtpliwie zalet ruterów dedykowanych jest obsBuga wielu protokoBów rutowania oraz dopracowane interfejsy umo|liwiajce ich konfiguracj. Rutery programowe pracujce w oparciu o hosty, obsBuguj zwykle jeden wybrany protokóB rutowania dynamicznego, a sposób ich konfigurowania czsto pozostawia wiele do |yczenia. Jednak|e niezaprzeczalnym atutem ruterów programowych jest ich niska cena oraz mo|liwo[ przeprowadzenia wielu eksperymentów w warunkach laboratoryjnych, co nie zawsze jest mo|liwe w przypadku rutera sprztowego wykorzystywanego najcz[ciej w typowej sieci. W przypadku budowy du|ej sieci konieczne jest, przed dokonaniem wyboru konkretnego urzdzenia, okre[lenie po|danych mo|liwo[ci funkcjonalnych rutera. Do podstawowych funkcji, zazwyczaj branych pod uwag (i wymaganych), zaliczy mo|na [1]: 1. ObsBug przynajmniej jednego protokoBu dynamicznego rutowania (RIP, OSPF, IGRP, EIGRP, BGP). 2. Mo|liwo[ przechowywania informacji o procesie rutowania w pliku jak równie| mo|liwo[ dynamicznego  zrzucania tych informacji do plików. 3. Dostpno[ interfejsu do konfiguracji rutera i zarzdzania ruterem (poprzez Telnet, protokóB HTTP ze stron WWW lub protokóB SNMP). Rutery sprztowe s urzdzeniami stosunkowo drogimi i wybór konkretnego rozwizania musi by poprzedzony wnikliw analiz potrzeb, stosunku zysków do kosztów, zasadno[ci wyboru danego urzdzenia z punktu widzenia np. planu modernizacji sieci w przyszBo[ci. Omawiane poni|ej oprogramowanie o nazwie Zebra umo|liwia emulowanie na komputerze klasy PC rutera CISCO, urzdzenia firmy wyznaczajcej od dawna standardy w zakresie wymiany informacji midzy ruterami jak i samej obsBugi tych urzdzeD. Wymienione oprogramowanie realizuje funkcje z pkt. 1-3 oraz daje mo|liwo[ sprawdzenia, w jaki sposób bdzie pracowaBa sie z ustalon konfiguracj rutingu. 2. Podstawowe informacje o protokoBach rutingu W rozdziale tym przedstawione zostan cechy charakterystyczne wybranych protokoBów rutingu dynamicznego: RIP, OSPF i BGP. Oprogramowanie realizujce funkcje tych protokoBów dostarczane s z pakietem Zebra. Jedn z najwa|niejszych funkcji rutera, obok wyboru drogi dla napBywajcego strumienia pakietów, jest utrzymywanie aktualnych tablic 52 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego trasowania (rutingu). W artykule pojcie rutingu odnosi si jedynie do procesu utrzymywania tych tablic i zarzdzania nimi. W odró|nieniu od rutingu statycznego (z niezmiennymi tablicami trasowania w pamici rutera) protokoBy rutingu dynamicznego sBu| do utrzymania aktualno[ci tablic nawet wtedy, gdy nastpuj zmiany sprztu, uszkodzenia Bczy sieciowych czy dodawane s nowe segmenty sieci. W celu cigBego aktualizowania tablic proces trasowania wysyBa oferty tras w postaci aktualizacji tras oraz odbiera i przetwarza uaktualnienia tras tak, aby trasy zapisywane w tablicy rutera byBy najbardziej efektywne. 2.1. Klasyfikacja protokoBów rutingu dynamicznego Dynamiczne protokoBy rutowania mo|na sklasyfikowa na kilka sposobów. Pierwszy zwizany jest z tym, jak cz[ sieci protokóB obejmuje swym zasigiem. Wyró|ni tutaj mo|emy [2]: " ProtokoBy zewntrzne (Exterior Gateway Protocols); " ProtokoBy wewntrzne (Interior Gateway Protocols). ProtokóB klasyfikowany jako zewntrzny odpowiada za wymian informacji o rutingu pomidzy dwiema niezale|nymi domenami administracyjnymi, zwanymi czsto systemami autonomicznymi. Najpopularniejszym obecnie protokoBem rutingu, wykorzystywanym pomidzy systemami autonomicznymi jest BGP (Border Gateway Protocol). Charakterystyczn cech protokoBów zewntrznych jest ich dobra skalowalno[ i przystosowanie do obsBugi du|ych sieci. SkBadaj si zwykle z wielu podprotokoBów, a ich implementacja jest do[ skomplikowana. Wewntrzne protokoBy rutingu stosowane s wewntrz pojedynczej domeny administracyjnej. Oznacza to, |e rutery nale|ce do ró|nych domen, nie komunikuj si ze sob bezpo[rednio. ProtokoBy posiadaj prostsz implementacj, w mniejszym stopniu obci|aj procesor i pami rutera. Najcz[ciej wykorzystywanymi reprezentantami tej klasy protokoBów s: RIP (Routing Information Protocol), OSPF (Open Shortest Path First) i EIGRP (Enhanced Interior Gateway Protocol). RIP i OSPF s standardami otwartymi, EIGRP jest natomiast opracowany przez Cisco Systems i stosowany jest w ruterach tej firmy. Innym kryterium klasyfikacji mo|e by sposób w jaki wykorzystywane s przez protokoBy rutingu informacje zawarte w tablicach rutingu i informacje dostarczane przez inne rutery. Wyró|ni tutaj mo|emy [2]: " protokoBy typu dystans-wektor (Distance - vector); Biuletyn Instytutu Automatyki i Robotyki, 16/2001 53 T. Malinowski " protokoBy stanu Bcza (Link - state). Reprezentantem protokoBów typu dystans-wektor jest historyczny i mocno dzi[ krytykowany (aczkolwiek nadal u|ywany) protokóB RIP, opisywany szczegóBowo w dokumentach RFC1058 (Routing Information Protocol. C.L. Hedrick) i RFC2453 (RIP Version 2. G. Malkin). ProtokoBy typu dystans-wektor regularnie rozsyBaj kompletne tablice rutingu. Pojedynczy zapis w tablicy dotyczcy danej drogi w sieci zwykle okre[la, obok adresu przeznaczenia i adresu nastpnego  skoku , ilo[ skoków do sieci docelowej (liczb ruterów na drodze pakietu do sieci docelowej). Liczba skoków jest tutaj jedyn miar jako[ci danej [cie|ki. W odró|nieniu od protokoBów dystans-wektor w protokoBach typu stan Bcza miara jako[ci danej trasy mo|e by wyznaczona z wykorzystaniem kilku wskazników takich jak: obci|enie sieci, pasmo przepustowo[ci danego Bcza, opóznienie na Bczu oraz inne parametry opisujce ruter. Dodatkowo, administrator sieci sam mo|e zdefiniowa miar administracyjn dla danego interfejsu rutera wykorzystywan przez proces rutingu. Ruter z protokoBem stanu Bcza nie przekazuje do ssiednich ruterów informacji o miejscach, które mo|na osign i w jaki sposób, lecz dostarcza informacje o topologii sieci. Przekazuje list segmentów lub Bczy, do których jest przyBczony bezpo[rednio oraz stan tych Bczy (czy funkcjonuj i jaki koszt jest z nimi zwizany). 2.2. ProtokóB RIP ProtokóB RIP [5] przeznaczony jest dla [rodowiska o stosunkowo prostej topologii z niewielk liczb ruterów poBczonych Bczami o takiej samej charakterystyce. ProtokóB ten, jako pierwszy protokóB typu IGP (Interior Gateway Protocol), byB powszechnie u|ywany i darmowo dystrybuowany w systemie Unix BSD, jako proces demon o nazwie routed. ProtokóB ten funkcjonuje do dzi[ w najnowszych dystrybucjach systemów unixowych, aczkolwiek w nieco od[wie|onej formie. RIP jest protokoBem typu dystans-wektor. Nazwa ta wywodzi si od zastosowanego tutaj algorytmu Bellmana-Forda wyznaczania najkrótszych [cie|ek w grafie obrazujcym topologi sieci. RIP wymaga zaanga|owania wszystkich ruterów (czasem równie| serwerów plików, aplikacji, bazodanowych, itp.) w proces utrzymywania aktualno[ci tras i oceny ich dBugo[ci. Zasada dziaBania rutera z protokoBem RIP jest bardzo prosta. Ka|dy ruter jest zaprogramowany tak, aby rozgBaszaB wszystkie cele (adresy sieci docelowych, czasem równie| hostów), które zna oraz odlegBo[ci do nich. Co okre[lony kwant czasu wysyBa w sie peBn informacj o wszystkich trasach 54 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego w znanej sobie topologii sieci. Po otrzymaniu podobnych informacji od innych ruterów zaczyna analizowa wszystkie mo|liwe cele i oblicza (wykorzystujc wspomniany algorytm Bellmana-Forda) najkrótsze [cie|ki do nich. Tylko najkrótsza [cie|ka dla danego celu jest zapisywana w tablicy rutingu. Tablica ta wykorzystywana jest przy wyborze drogi dla napBywajcego strumienia pakietów. Kluczowym aspektem dziaBania protokoBów typu dystans-wektor jest to, |e dowolny ruter zna tylko kolejny krok w sekwencji dostarczania pakietów do ich miejsca przeznaczenia. ProtokóB RIP funkcjonuje do dzi[, jest szeroko u|ywany i jest jedynym protokoBem trasowania  rozumianym przez wszystkie komputery u|ywajce systemów operacyjnych typu Unix. Niestety protokóB ten posiada szereg wad i ograniczeD, które dyskwalifikuj go w roli protokoBu rutingu dla du|ych sieci. Z zaBo|enia ka|dy ruter z uruchomionym protokoBem RIP co 30 sekund wysyBa tzw. aktualizacje RIP. Aktualizacje te to wszystkie zapisy dotyczce znanych tras z tablicy rutingu rutera. Je[li wic tych tras jest du|o, kilka ruterów z protokoBem RIP potrafi  skonsumowa znaczn cz[ przepustowo[ci sieci. Informacja dotyczca pojedynczej trasy zawiera: " adres docelowego hosta lub sieci; " adres IP rutera (bramki) wysyBajcego aktualizacj; " warto[ wskazujc odlegBo[ (w sensie liczby skoków) do celu. W momencie otrzymania aktualizacji trasy od ssiedniego rutera, ruter porównuje przyjt informacj z zawarto[ci wBasnej tablicy trasowania. W przypadku, gdy aktualizacja dotyczy nowej trasy, trasa jest dodawana do tablicy rutingu. Je[li ruter otrzyma informacj o istniejcej w tablicy trasie, z mniejsz liczb skoków do danego celu, stary zapis o osigalno[ci tego celu jest zastpowany [wie| informacj. Oczywi[cie istnieje tutaj zabezpieczenie przed sytuacjami kiedy dana trasa przestaje funkcjonowa (uszkodzenie linii, uszkodzenie rutera na drodze do sieci docelowej). Ruter RIP pamita niestety tylko jedn, najlepsz tras. W jego tablicy trasowania brak jest zapisów dotyczcych tras alternatywnych. Do sterowania sytuacjami awaryjnymi RIP u|ywa czasomierzy. Obok zegara sterujcego wysyBaniem aktualizacji tras (domy[lnie co 30s) wykorzystywany jest zegar zliczajcy dla ka|dej z tras czas jaki upBynB od jej ostatniej aktualizacji. Je|eli ruter nie otrzyma aktualizacji danej trasy w przecigu 180 s trasa zaznaczana jest jako nieosigalna. Po stwierdzeniu nieosigalno[ci trasy ruter wysyBa specjaln wiadomo[ informujc ssiadów o zaistniaBej sytuacji. Po 270s nieosigalna i zarazem nieaktualna trasa jest usuwana z tablicy rutingu rutera. Kolejne zegary nosz nazw czasomierzy: aktualizacji (update), bBdu (invalid) i usuwania (flush). Biuletyn Instytutu Automatyki i Robotyki, 16/2001 55 T. Malinowski Podsumowujc, protokóB RIP posiada szereg ograniczeD i przez to nie nadaje si do wykorzystania w du|ych sieciach. Najwa|niejsze z nich to, |e [3]: - miar jako[ci danej [cie|ki RIP jest liczba skoków. RIP zakBada maksymaln liczb skoków równ 15. Sie, do której odlegBo[ wynosi 15 skoków jest dla protokoBu RIP nieosigalna; - liczba skoków jest jedyn miar jako[ci danej trasy, co w przypadku istnienia alternatywnych,  szybszych tras, ale o wikszej liczbie skoków, przekre[la ich zastosowanie w procesie wyboru drogi dla pakietu; - RIP w wersji 1 nie potrafi obsBugiwa podsieci o ró|nych wielko[ciach (ruting klasowy); - okresowa wymiana caBych tablic rutingu wprowadza znaczne obci|enie sieci; - konwergencja sieci z protokoBem RIP jest wolniejsza ni| dla protokoBów typu link-state; - sieci RIP s sieciami pBaskimi. Nie zakBada si ich podziaBu na obszary, nie wyznacza si granic tych obszarów. Pewne modyfikacje wprowadzone zostaBy w RIP2 (VLMS, autentication, multicast routing updates, "split horizon") [4]. Nadal jednak podstawow miar rutingu pozostaje liczba skoków, nadal jej maksymalna warto[ to 15 (warto[ 16 odpowiada nieosigalno[ci miejsca przeznaczenia). 2.3. ProtokóB OSPF ProtokóB OSPF [7] opracowany zostaB w koDcu lat 80-tych. W odró|nieniu od RIP bazuje on na przesyBaniu do swoich ssiadów jedynie istotnych wycigów z tablic rutingu. OSPF jest protokoBem typu stanu Bcza (link-state), wic przesyBane informacje dotycz jedynie charakterystyk wBasnych interfejsów rutera. W celu utrzymania tablic rutingu protokóB wykorzystuje 5 rodzajów komunikatów [2]: 1. Komunikaty  hello . 2. Opisy baz danych (database descriptions). 3. {dania danych o stanie poBczeD (request link-state). 4. Dane aktualizujce stan poBczeD (updates link-state). 5. Potwierdzenia stanu poBczeD (acknowledgments link-state). Komunikaty nr 4 s wBa[ciwymi komunikatami, na podstawie których wyznaczane i utrzymywane s tabele rutingu. Komunikaty te obejmuj tzw. ogBoszenia LSA (link-state advertisements). Jest kilka rodzajów komunikatów 56 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego LSA i nie mog by one mylone z wymienionymi wy|ej rodzajami komunikatów. Wymiana ogBoszeD LSA umo|liwia utworzenie przez ruter bazy danych o stanie Bczy (stanie wBasnych interfejsów i interfejsów innych ruterów w sieci). Na podstawie tej bazy danych, z wykorzystaniem dobrze znanego z teorii grafów algorytmu Dijkstry, ruter oblicza najkrótsze [cie|ki w sieci. Pierwsz operacj po wBczeniu rutera z protokoBem OSPF jest wysBanie komunikatu  hello na wszystkie swoje interfejsy, do wszystkich ruterów OSPF w sieci. Na podstawie odpowiedzi na wysBane komunikaty  hello ruter odkrywa, kto jest jego ssiadem tzn. z którymi ruterami mo|e komunikowa si bez po[rednictwa innych ruterów. Dla caBej sieci, po krótkim okresie wymiany komunikatów  hello , ustalone zostan sieciowe grupy ssiedzkie. Po ustaleniu swoich ssiadów ruter próbuje zbudowa tablic wzajemnych powizaD z nimi. Okre[lonych jest siedem poziomów wzajemnych odniesieD pomidzy ruterami OSPF: od stanu tzw. zaniku poBczenia (down state) do stanu peBnego ssiedztwa (fully adjacent state). W stanie zaniku poBczenia rutery w ogóle nie mog komunikowa si ze sob, a w stanie peBnego ssiedztwa wymieniaj wszystkie 5 rodzajów komunikatów OSPF. Kiedy rutery dokonaj wymiany ogBoszeD LSA, na ka|dym z nich ukoDczone zostanie ustawienie takiej samej bazy danych o poBczeniach (database of links), czyli mapy topologii sieci. Na jej podstawie ruter z algorytmem Dijkstry buduje tablice rutingu, wykorzystywan do kierowania ruchem napBywajcych pakietów. Na podstawie skutków ró|nych zdarzeD (uszkodzenie kabla, uszkodzenie interfejsu, itd.) rutery zmieniaj dane o stanie poBczeD. Baza o stanie poBczeD musi by aktualizowana na bie|co, wszystkie rutery powinny posiada identyczn baz. W przeciwnym razie obraz sieci byBby niespójny. W konsekwencji tego zaBo|enia, je[li ruter nie otrzymuje od swego ssiada przez pewien czas (tzw. przedziaB martwy  dead interval) |adnej wiadomo[ci, uzna, |e Bcze utraciBo stan gotowo[ci do dziaBania. Stan ten jest okre[lany mianem  poBczenie przej[ciowe (link transition). Informacja o stanie przej[ciowym musi by natychmiast wymieniona ze wszystkimi ruterami OSPF, by mogBy przeprowadzi rekalkulacj swych tablic rutingu. Proces synchronizowania baz danych przez rutery nazywany jest konwergencj (convergence). Zwykle zale|y nam na jak najkrótszym czasie konwergencji, po którym obraz sieci staje si spójny. W typowej sieci konwergencja dokonuje si w przecigu milisekund. Obszary OSPF Kiedy grupa sieci i ruterów staje si zbyt du|a, mo|e by podzielona na obszary (struktur hierarchiczn, okre[lon ponad struktur odpowiadajc adresacji IP). Biuletyn Instytutu Automatyki i Robotyki, 16/2001 57 T. Malinowski ProtokóB OSPF do prawidBowego funkcjonowania wymaga zdefiniowania tzw. obszarów. Wymagane jest zdefiniowanie przynajmniej jednego obszaru, nazywanego obszarem szkieletu, do którego bd nale|aBy wszystkie tzw. rutery brzegowe (graniczne) OSPF. Rysunek 1 przedstawia przykBadow struktur sieci z umiejscowionym centralnie obszarem szkieletu (Obszar 0) i doBczonymi do szkieletu obszarami o numerach 1, 2 i 3. Rys.1. PrzykBadowa struktura sieci OSPF. Ka|dy z obszarów mo|e obejmowa kilka podsieci, zgrupowanych z wykorzystaniem techniki grupowania, omówionej w dalszej kolejno[ci. W protokole OSPF odpowiedzialno[ za funkcjonowanie sieci spada na obszar szkieletu. Poszczególne obszary nie wspóBdziaBaj ze sob w ramach OSPF. Konstruowanie obszarów pozwala zredukowa rozmiar bazy danych o poBczeniach w ka|dym ruterze (wymóg posiadania identycznych baz danych zostaje ograniczony do obszaru). Rutery umiejscowione na granicy obszarów (posiadajce interfejs Bczcy je ze szkieletem sieci i przynajmniej jeden interfejs do obszaru nie zerowego nazywane s ruterami brzegowymi obszarów tzw. ABR-ami (Area Border Router). Jedn z funkcji rutera ABR jest zapewnienie obszarowi OSPF dostpu do szkieletu sieci. Przy wyborze obszarów nale|y zachowa daleko posunit ostro|no[, chocia|by z tego powodu, |e caBy ruch pakietów bdzie odbywaB si przez obszar zerowy nawet w przypadku, gdy pomidzy obszarami istniej alternatywne, by mo|e szybsze Bcza. Obszary OSPF maj przydzielone identyfikatory ID obszaru, które maj tak sam notacj dziesitn jak adresy IP (adresy te nie powinny by jednak ze sob mylone). W praktyce obszary OSPF s czsto okre[lane skrótowo 58 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego pojedyncz liczb (1, 2,... itd. które s odpowiednikiem numerów ID: 0.0.0.1, 0.0.0.2, itd.). Rutery desygnowane Obok pomysBu dekompozycji sieci na obszary, w protokole OSPF wprowadzona zostaBa koncepcja wyró|nienia niektórych ruterów do speBniania specjalnych funkcji. Rutery OSPF dokonuj wyboru spo[ród siebie reprezentanta, który przejmuje obsBug swoich ssiadów przy kontaktach z innymi ruterami w sieci, tzw. rutera desygnowanego DR (designated router). a) b) Rys.2. Schemat poBczeD (sesji) midzy ruterami OSPF dla przypadku: a) bez wyboru ruterów desygnowanych, b) z wybranym DR i BDR. W tym samym czasie wybierany jest równie| zapasowy ruter desygnowany BDR (backup designated router). Funkcja rutera desygnowanego sprowadza si do czuwania nad spójno[ci obrazu sieci w ka|dym z ruterów. Obecno[ DR-a i BDR-a w sieciach z wielodostpem rozgBoszeniowym (przykBadowo sie Ethernet) redukuje liczb tras komunikacyjnych (powizaD ssiedzkich pomidzy ruterami). W efekcie zmniejsza si ruch multicastowy w sieci. Na rysunku 2 przedstawiony jest schemat powizaD midzy ruterami w sieci bez ruterów desygnowanych i z wybranymi DR i BDR. Liczba wzajemnych poBczeD (sesji), przy N-ruterach w sieci, dla przypadku bez DR/BDR jest okre[lona przez N*(N-1)/2. Dla przypadku z wybranymi ruterami desygnowanymi (N-1)+(N-2). W podanym przykBadzie zysk jest niewielki (liczba sesji zredukowana zostaje z 6 do 5). Stosownie DR-a i BDR-a nabiera wikszego znaczenia przy wikszej liczbie ruterów. Wybór rutera desygnowanego i zapasowego rutera desygnowanego dokonywany jest z wykorzystaniem pakietów  hello . Pakiet ten zawiera pole przeznaczone na priorytet rutera (0-255). Warto[ priorytetu rutera ustalona mo|e by podczas Biuletyn Instytutu Automatyki i Robotyki, 16/2001 59 T. Malinowski jego konfiguracji. W procesie elekcji rutery wymieniaj pakiety  hello i wybieraj spo[ród siebie dwa rutery o najwy|szych priorytetach. Proces reelekcji nie dokonuje si automatycznie. PodprotokoBy OSPF ProtokóB OSPF jest do[ skomplikowanym protokoBem. W jego skBad wchodz trzy podprotokoBy:  Hello ,  Exchange i  Flooding . PodprotokoBy OSPF operuj w ró|nych stadiach wzajemnych kontaktów pomidzy ruterami OSPF. PodprotokóB  Hello dziaBa podczas wzajemnego rozpoznawania si ruterów (poszukiwania ssiadów).  Exchange pojawia si wtedy, gdy dwa rutery uznaj, |e chc wymieni (uszczegóBowi) swoje dane.  Flooding jest u|ywany w przypadku, gdy rutery zakoDcz budow tabel przylegBo[ci wskazujc, |e od tego momentu mog by wymieniane wszystkie rodzaje komunikatów OSPF (5 typów komunikatów wymienionych wcze[niej). PodprotokóB  Hello uBatwia elekcj DR i BDR. RozsyBane s multicastowo przez pewien bardzo krótki przedziaB czasu (kilka sekund). Zawieraj w sobie pole priorytetu rutera, warto[ okresu  hello oraz okresu martwego i identyfikatory ID wszystkich ruterów ssiedzkich. Je|eli przez okres martwy nie ma reakcji ze strony ssiada, wtedy ruter ogBasza, |e jego poBczenie z ssiadem staBo si nieczynne. WysyBa multicastowo komunikat aktualizujcy stan poBczeD wykorzystujc do tego celu protokóB  Flooding . PodprotokóB  Exchange uruchamiany jest po tym jak rutery okre[l zakres wzajemnych powizaD ssiedzkich (korzystajc z  Hello ). Rozpoczynaj wtedy synchronizowania baz danych o stanie poBczeD. Za pomoc protokoBu  Exchange dokonywana jest wymiana informacji o stanie poBczeD. Proces wymiany odbywa si stopniowo, fragmentami. Takie fragmenty baz danych zawieraj komunikaty opisu baz danych (database description  komunikaty typu 2). Idea wymiany cz[ciowych opisów polega na dostarczeniu ruterom tylko takiej informacji (takiej cz[ci), która pozwoli im okre[li, czy s oni zainteresowani poszczególnymi rekordami o stanie poBczeD. Z punktu widzenia rutera interesujce dla niego s tylko takie rekordy, które ró|ni si od posiadanych we wBasnej bazie lub po prostu nie istniej. Kiedy ruter stwierdzi, |e jest zainteresowany pewnymi rekordami, zgBasza na nie zapotrzebowanie z pomoc komunikatu OSPF nr 3. PeBne rekordy zwracane s za pomoc komunikatu OSPF typu 4.  Exchange jest najbardziej skomplikowanym z podprotokoBów OSPF, ale wykorzystywany jest najrzadziej. W stabilnej sieci ruch generowany przez OSPF w dominujcej cz[ci zwizany bdzie z komunikatami  Hello i od czasu do czasu pojawiajcym si wylewem informacji o stanie poBczeD (protokóB  Flooding ). PodprotokóB  Flooding sBu|y do zsynchronizowania baz danych o stanie poBczeD midzy ruterami po zbudowaniu przez nie peBnych powizaD. 60 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego Wykorzystywane s tutaj komunikaty typu 4 (dane aktualizujce stan Bcza) oraz typu 5 (potwierdzenia stanu Bcza).  Flooding stosowany jest przez rutery w trzech sytuacjach: a) do powiadomienia swoich ssiadów o stanie przej[ciowym Bcza  zawsze po tym, jak ruter stanie si [wiadom jakiegokolwiek problemu na którym[ ze swoich interfejsów (np. w momencie zaniku napBywu pakietów  hello od ssiada); b) przy cyklicznie rozsyBanych w ustalonych okresach danych aktualizujcych o stanie Bczy (zazwyczaj co 30 minut); c) przy wysyBaniu danych aktualizujcych o rekordach zdezaktualizowanych. Wszystkie rekordy w bazie posiadaj swoje liczniki czasu. Kiedy licznik osignie maksymaln dopuszczaln warto[ (zwykle 1 godz.) rekord taki nie bdzie uwzgldniany przy wyborze tras i zostaje zaznaczony jako rekord do usunicia. W konsekwencji zdezaktualizowane rekordy s  wylewane , aby mogBy by usunite jak najszybciej z baz wszystkich ruterów. Technika grupowania Technika tworzenia grup w OSPF (summarization) pozwala ruterom ABR na zgBaszanie mniejszej liczby tras dotyczcych tych obszarów, które s przez nie wBczone do szkieletu sieci. Warunkiem stosowania techniki grupowania jest to, aby numery sieci, które maj by poBczone byBy w bliskim ssiedztwie. Na rysunku 3 przedstawione zostaBo przykBadowe [rodowisko rutingu, w którym zastosowane bdzie grupowanie sieci. ZaBó|my, |e wszystkie rutery na rysunku, nale| do jednego obszaru i |e tylko jeden z nich (w przykBadzie nie jest istotne który) posiada dodatkowy interfejs doBczajcy go do obszaru zerowego (szkieletu) sieci. Ruter ten bdzie komunikowaB si w imieniu pozostaBych ruterów z innymi ruterami szkieletowymi zgBaszajc im, jak wyglda topologia obszaru niezerowego, do którego sam nale|y. ZaBó|my, |e administrator sieci chce zamaskowa dla innych ruterów szczegóBy podanej konfiguracji sieci nale|cych do obszaru o identyfikatorze ID=1. Najpro[ciej pogrupowa sieci w ramach nowej podsieci i skonfigurowa ruter tak, aby do szkieletu zgBaszaB tylko jedn tras dotyczc sieci sumarycznej. Biuletyn Instytutu Automatyki i Robotyki, 16/2001 61 T. Malinowski Rys.3. PrzykBadowe [rodowisko rutingu Niech sieci o numerach: - 172.168.33.0 - 172.168.34.0 - 172.168.35.0 - 172.168.36.0 bd sieciami typu ethernet, natomiast sieci o adresach 172.168.40.0 i 172.168.41.0 bd sieciami typu punkt-punkt. Zwrómy uwag, |e pierwsze dwa oktety w adresach wszystkich sieci s identyczne. Mo|na wic dokona prostego grupowania podsieci w jedn sie o nowym adresie 172.168.0.0 (stanowicym cz[ wspóln wszystkich adresów) i masce 255.255.0.0. Aatwo zauwa|y, |e w tak wyznaczonej sieci grupowej istnieje miejsce na 254 podsieci ethernet lub punkt-punkt o adresach z zakresu 172.168.1.0  172.168.254.0. Z punktu widzenia administratora sieci, taki sposób grupowania mo|e oznacza utrat du|ej puli adresów IP (nie wykorzystane w przedstawionej konfiguracji adresy). Dokonujc konwersji 62 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego adresów IP z notacji dziesitnej na binarn zauwa|amy, |e wspólna cz[ wszystkich adresów to 20 bitów. Sieci grupowej mo|na wic przypisa adres 172.168.32.0. DBugo[ grupowej maski odpowiadajca wspólnej cz[ci adresów wszystkich sieci wynosi wic 20 bitów, co odpowiada masce 255.255.240.0. W rozwa|anym przykBadzie zakres adresów sieci, które mie[ciByby si w ramach grupowego zgBoszenia zawiera si w przedziale 172.168.32.0  172.168.47.0. Zamiast jednego grupowego zgBoszenia mo|na posBugiwa si kilkoma, np. jednym dla wszystkich sieci ethernet i drugim dla sieci punkt-punkt. Aatwo zauwa|y, |e dla sieci typu ethernet wspólna cz[ adresowa to 21-bitów, dla sieci typu punkt-punkt 23 bity. Sie grupujca sieci ethernet miBaby wic adres 172.168.32.0 z mask 255.255.248.0 (mo|liwo[ zgrupowania sieci o adresach z przedziaBu 172.168.32.0-172.168.39.0), za[ adres drugiej sieci grupowej wynosiBby 172.168.40.0 z mask 255.255.254.0 (co daje mo|liwo[ zgrupowania sieci z adresami z zakresu 172.168.40.0-172.168.41.0). Przy konfigurowaniu protokoBu OSPF w zBo|onych sieciach, nale|y zwróci uwag na nastpujce wskazówki implementacyjne [2]: - je[li jest to mo|liwe nale|y dzieli zBo|on sie na mniejsze cz[ci; - nale|y unika sytuacji, w których jaki[ ruter peBni rol rutera desygnowanego dla kilku obszarów OSPF; - nale|y unika stosowania rutera ABR w roli rutera desygnowanego, poniewa| obsBugiwaBby on dwie kopie baz danych o stanie poBczeD: jedn dla obszaru szkieletowego, drug dla obszaru, który jest doBczony do sieci szkieletowej; - nale|y korzysta z techniki grupowania sieci, dla celów zbiorczego zgBaszania ich do obszaru szkieletowego i innych obszarów. Pozwala to na redukcj zajto[ci pasma sieciowego (mniejsza liczba LSA do przetworzenia oraz mniejszy roamiar tabel rutingu). 2.4. ProtokóB BGP ProtokóB BGP [8] umo|liwia przekazywanie pakietów z danymi u|ytkowymi pomidzy odlegBymi lokalizacjami w Internecie, tzn. pomidzy du|ymi systemami zarzdzanymi przez operatorów sieci, zwanymi systemami autonomicznymi (s to systemy typu  transit ,  multihomed i  stub ). Ka|dy system autonomiczny jest rejestrowany przez organizacj InterNIC, gdzie przydzielany jest mu odpowiedni numer. Numery te s wykorzystywane podczas konfigurowania ruterów dla BGP. W systemie autonomicznym jeden lub wicej ruterów, które zostaj skonfigurowane do obsBugi BGP, staj si speakerami BGP (reprezentantami Biuletyn Instytutu Automatyki i Robotyki, 16/2001 63 T. Malinowski pozostaBych ruterów i sieci tworzcych system autonomiczny). Speakery wiedz wszystko o konfiguracji sieci w ramach AS. Odbieraj tak|e komunikaty aktualizujce ruting z danymi o sieciach z innych systemów autonomicznych. Przekazuj swoim partnerom aktualizacje rutingu zarówno sieci wewntrznych jak i sieci z innych AS. Dowolne rutery skonfigurowane do obsBugi BGP wymieniajce aktualizacje rutingu nazywane s BGP peers (partnerzy BGP). Ruter BGP pozyskuje dane o swoich ssiadach za pomoc protokoBu TCP korzystajc z powszechnie znanego portu o numerze 179. Adresy IP oraz numery systemów autonomicznych ze wszystkich partnerskich ruterów BGP, które konfigurowany ruter bdzie dostrzegaB, musz by wyspecyfikowane za pomoc polecenia konfiguracyjnego  neighbor . Po nawizaniu poBczenia TCP pomidzy partnerami BGP do wzajemnego komunikowania wykorzystywane s 4 rodzaje komunikatów: open, update, keepalive i notification. Najbardziej u|ytecznym jest update, który sBu|y do przekazywania informacji o rutingu. Komunikaty open i keepalive wykorzystywane s do nawizania i utrzymywania sesji BGP. Komunikat notification sBu|y do powiadamiania o bBdnych warunkach pomidzy partnerskimi BGP. Partnerzy BGP mog by zarówno wewntrzni jak i zewntrzni. Wewntrzni partnerzy buduj (nawizuj) sesj w ramach jednego systemu autonomicznego, a partnerzy zewntrzni to rutery nale|ce do ró|nych systemów autonomicznych. ProtokóB BGP posiada mo|liwo[ realizacji nastpujcych funkcji: - agregacji tras; - egzekwowania reguB ró|nej polityki rutingu dla ró|nych systemów autonomicznych; - poprawy skalowalno[ci poprzez wykorzystanie dla tras reflektorów i konfederacji; - wspóBdziaBanie z protokoBami IGP poprzez redystrybucj i synchronizacj. Agregacja tras jest realizowana podobnie jak dla protokoBu OSPF, z t ró|nic, |e dla BGP zagregowane adresy sieci i ich maski wyznaczane s na poziomie systemu autonomicznego, a nie obszaru. Dziki funkcji agregacji tras mo|na zredukowa liczb tras (sieci) w ramach systemów autonomicznych, które rutery BGP bd ogBasza dla swoich zewntrznych partnerów. Proces BGP pracujcy na ruterze musi by specjalnie poinformowany poprzez odpowiednie polecenia konfiguracyjne, |e ma obsBugiwa agregacj tras. Koncepcja agregacji tras jest bardzo prosta, aczkolwiek szczegóBy implementacji i opcje konfiguracyjne s bardzo zBo|one [3]. 64 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego Pomidzy procesami realizujcymi ró|ne protokoBy rutingu mo|liwa jest redystrybucja tras. Mo|na tutaj dystrybuowa trasy statyczne zapisane w tabelach tras rutera (redystrybucja statyczna) jak i trasy otrzymywane od innych ruterów i ró|nych protokoBów rutingu (redystrybucja dynamiczna). Redystrybucja dynamiczna polega na zleceniu procesowi BGP akceptacji tras zgBaszanych przez protokóB typu IGP (RIP, OSPF, IGRP...). Wymaga to jednak takiego skonfigurowania procesu IGP, aby dystrybuowaB on swoje trasy dla BGP. Mo|liwa jest wzajemna redystrybucja tras, zarówno statyczna jak i dynamiczna, pomidzy protokoBami BGP a IGP. Na rysunku 4 przedstawiony zostaB przykBad [rodowiska, w którym mo|liwe jest zastosowanie redystrybucji statycznej i dynamicznej midzy protokoBami OSPF i BGP. Liniami cigBymi zaznaczone zostaBy sesje BGP, liniami przerywanymi sesje OSPF. Jak wida, na ruterach ASBR (Autonomous System Border Router) powinny by uruchomione dwa procesy: OSPF i BGP. Podstawowy przepByw danych o osigalnych sieciach dokonuje si z IGP (tutaj procesu OSPF) do BGP. Proces BGP uruchomiony na ASBR dowiaduje si o sieciach w systemie AS za pomoc redystrybucji statycznej, dynamicznej lub za pomoc odpowiedniego polecenia konfiguracyjnego (np. network, udostpnianego przez system sieciowy IOS Cisco). Rys.4. Ruting OSPF i BGP wewntrz systemu autonomicznego. Biuletyn Instytutu Automatyki i Robotyki, 16/2001 65 T. Malinowski W przypadku jakiejkolwiek niestabilno[ci w pracy sieci obsBugiwanych np. przez protokóB OSPF dane o trasach redystrybuowane s w sposób dynamiczny. Jakakolwiek zmiana w trasach OSPF powoduje wygenerowanie danych do aktualizacji dla BGP. Poziom ruchu w sieci staje si w tym momencie znaczny. Scenariusz ten nosi nazw  trzepotania tras . Jedynym sposobem uniknicia trzepotania tras jest redystrybucja statyczna. Je[li wewntrz AS znajduje si bardzo du|o sieci OSPF dostarczanie informacji o ka|dej z nich do zewntrznego rutera BGP jest niepo|dane. Sytuacja ta kwalifikuje si do przedstawienia tych sieci za pomoc metody agregacji tras. Aby rutery BGP mogBy komunikowa si ze sob musz by skonfigurowane jako ssiedzkie. Liczba sesji TCP w ruterach przy konfiguracji poBczeD typu ka|dy z ka|dym (tzw.  full-meshed ) mo|e by znaczna. Aby zminimalizowa liczb sesji stosuje si metod odzwierciedlania tras i metod konfederowania [9]. Odzwierciedlanie tras jest technik podobn do stosowania rutera desygnowanego. Rysunek 5 przedstawia powizania midzy ruterami BGP przy zastosowaniu odzwierciedlania tras. Rys.5. Technika odzwierciedlania tras w BGP. ZakBada si, |e Ruter A jest skonfigurowany do peBnienia roli zwierciadBa tras i przyjmuje zewntrzne dane aktualizacyjne BGP. Rozpowszechnia je do wszystkich swoich partnerów. Je[li inny ruter zostanie skonfigurowany jako klient zwierciadBa, bdzie przesyBaB dane aktualizacyjne tylko do rutera odzwierciedlajcego. Ten za[ odbije (ponownie ogBosi) je do swoich partnerów. Redukowana w ten sposób jest liczba sesji BGP. Grupa ruterów skonfigurowana do uczestnictwa w odzwierciedlaniu tras nazywana jest  klastrem . 66 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego Inn metod redukowania wzajemnych powizaD wewntrznych BGP w ramach systemu AS zawierajcego du| liczb speakerów s  konfederacje . W metodzie tej poszczególne speakery grupuje si w mini-ASy. Konfederacje BGP definiowane s za pomoc poleceD konfiguracyjnych ruterów. BGP jest protokoBem typu path-vector. Zcie|ka odnosi si do serii kroków, które musz by podjte pomidzy punktem pocztkowym, a docelowym. Zcie|ka BGP jest wic seri liczb z numerami AS, przez które bd przechodzi pakiety, aby dotrze do miejsca przeznaczenia. Kompletny opis [cie|ki dokonywany jest poprzez zestawienie jej atrybutów, co nie bdzie tutaj omawiane. Atrybuty [cie|ek przenoszone s w komunikatach aktualizacyjnych (update messages), wymienianych midzy speakerami BGP. 3. Pakiet GNU Zebra Pakiet o nazwie Zebra [10] jest niekomercyjnym zbiorem oprogramowania realizujcego wybrane protokoBy rutingu na dedykowanym do tego celu komputerze, pracujcym pod kontrol unixowego systemu operacyjnego. Umo|liwia wymian tablic routingu zgodnie z zasadami wymiany komunikatów dla protokoBów RIP, BGP, OSPF. Wymieniane tablice rutingu s u|ywane do uaktualnienia systemowych (kernelowych) tablic rutingu. Pakiet umo|liwia dynamiczn zmian tablic rutingu oraz jej przegldanie z poziomu terminala Zebry. System z zainstalowanym oprogramowaniem pracuje jako dedykowany ruter programowo realizujcy wybrane funkcje rutera firmy Cisco Systems. W przypadku maBej sieci konfiguracja Zebry sprowadza si do skonfigurowania kart sieciowych i dodaniu kilku poleceD dotyczcych rutingu statycznego i domy[lnych bram (gateways). W przypadku sieci bardziej rozbudowanej lub dla sieci niestabilnej (ze zmieniajc si struktur) mo|liwe jest wykorzystanie protokoBów rutingu dynamicznego (RIP, OSPF,BGP). Tradycyjne oprogramowanie rutingu (znane z ró|nych dystrybucji systemu Unix) dostarczane jest w postaci pojedynczego procesu-demona. Wikszo[ poleceD konfigurujcych ruting dostpna jest jedynie dla administratora systemu. Zebra opiera si na rozwizaniu innym. Jest produktem skBadajcym si z kilku procesów-demonów pracujcych równocze[nie i operujcych na pojedynczej tablicy rutingu. Demon o nazwie zebra stanowi jdro systemu rutingu (kernel routing manager). Nieco inny ni| w ruterze sprztowym jest sposób zarzdzania rutingiem [11]. Mo|liwe jest komunikowanie si z ruterem w trybie zwykBego u|ytkownika (user mode) oraz w trybie uprzywilejowanym (enable mode user  odpowiadajcy trybowi privilage rutera firmy Cisco Systems). Biuletyn Instytutu Automatyki i Robotyki, 16/2001 67 T. Malinowski Omawiane oprogramowanie jest dostpne pod adresem ftp://ftp.zebra.org/pub/zebra. ObsBugiwane przez Zebr protokoBy routingu to: 1. Border Gateway Protocol 4 (BGP-4) opisywany przez RFC1771. 2. OSPF v.2  RFC2328. 3. RIP v.2  RFC2453. 4. RIPng for IPv6  RFC2080. 3.1. Architektura oprogramowania Za realizacje funkcji poszczególnych protokoBów rutingu (omawianych w niniejszym opracowaniu) odpowiedzialne s wyizolowane procesy, odpowiednio: ripd (protokóB RIP), ospfd (protokóB OSPF) i bgpd (protokóB BGP). Za zmian systemowych tablic rutingu (kernel routing table) oraz redystrybucj tras pomidzy procesami rutingu odpowiedzialny jest demon zebra. ModuBowa architektura systemu (rysunek 6) umo|liwia dodanie kolejnych procesów-demonów, realizujcych inne protokoBy rutingu, bez szczególnej ingerencji w zainstalowane oprogramowanie. Oczywi[cie mo|liwe jest równolegBe uruchomienie kilku procesów realizujcych ten sam protokóB. bgpd ripd Ospfd zebra Tablica rutingu systemu Unix Rys.6. Architektura systemu Zebra W trakcie opracowywania artykuBu Zebra zostaBa przetestowana na nastpujcych platformach systemowych: " GNU/Linux 2.0.37, " GNU/Linux 2.2.x, " GNU/Linux 2.3.x, " FreeBSD 2.2.8, " FreeBSD 3.1, " FreeBSD 4.x. Prowadzone s prace nad oprogramowaniem dla systemów: " GNU/Hurd 0.2, " Solaris 7. 68 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego 3.2. Pliki konfiguracyjne zebry i pozostaBych demonów Instalacja pakietu zebra (opisywana szczegóBowo w dokumentacji [11]) koDczy si skopiowaniem skompilowanych programów i plików konfiguracyjnych do standardowych lokalizacji dla systemu Linux (/usr/local/bin i /usr/local/etc). Demony wchodzce w skBad pakietu dostpne s poprzez wBasne, dedykowane interfejsy. Po instalacji oprogramowania (tutaj w wersji 0.86) nale|y zadba o wBa[ciwe przyporzdkowanie im numerów portów. Niezbdne jest dodanie nastpujcych zapisów do pliku /etc/services: zebrasrv 2600/tcp # ZEBRA service zebra 2601/tcp # ZEBRA vty ripd 2602/tcp # RIPd vty ripngd 2603/tcp # RIPngd vty ospfd 2604/tcp # OSPFd vty bgpd 2605/tcp #BGPd vty ospf6d 2606/tcp # OSPF6d vty gdzie ripngd oraz ospf6d s procesami dziaBajcymi w oparciu o protokóB IPv6. Virtual Terminal Interface (VTY) - interfejs terminalowy - umo|liwia poBczenie z demonem przez protokóB telnet. Ka|dy demon posiada swój wBasny plik konfiguracyjny (odpowiednio: zebra.conf, ripd.conf, ospfd.conf i bgpd.conf). PrzykBadowa zawarto[ plików omówiona zostanie w dalszej kolejno[ci. Odpowiednio skonfigurowane procesy mog realizowa nastpujce funkcje: W przypadku protokoBu RIP: - posBugiwanie si sposobem adresacji z wersji 1 (maska okre[lana jest na podstawie klasy adresu IP) jak równie| posBugiwanie si VLSM (RIP v.2 jest domy[lnym protokoBem); - zablokowanie / odblokowanie procesu RIP; - ustalenie wykorzystywanej wersji RIP (v.1, v.2); - zablokowanie / odblokowanie danego interfejsu sieciowego (przekazywania pakietów RIP do/z wyspecyfikowanej sieci); - specyfikacja ssiadów dla RIP (w przypadku gdy ssiednie rutery RIP nie obsBuguj trybu multicast  zdefiniowanie [cie|ki midzy ruterami tzw. direct link); - odblokowanie / zablokowanie redystrybucji statycznych tablic rutingu; - zdefiniowanie zegarów : update, timeout, garbage, odpowiadajcych wymienionym wcze[niej czasomierzom: update, invalid i flush; Biuletyn Instytutu Automatyki i Robotyki, 16/2001 69 T. Malinowski - ustalenie tzw. rip authentication string, czyli klucza autentykacji, jakim bdzie posBugiwaB si ruter przy przesyBaniu uaktualnieD przez dany interfejs lub do okre[lonego ssiada; - zablokowanie / odblokowanie odbierania pakietów RIP konkretnej wersji protokoBu; - filtrowanie pakietów zgodnie z list dostpu, tzw. access list; - [ledzenie na bie|co wymienianych komunikatów. Dla procesu OSPF: - realizacja zaBo|eD protokoBu ver2 (RFC2178); - odblokowanie / zablokowanie procesu OSPF - odblokowanie / zablokowanie konkretnego interfejsu; - definiowanie obszarów OSPF; - grupowanie tras; - definiowanie wirtualnych [cie|ek dla obszarów nie poBczonych bezpo[rednio ze szkieletem sieci; - redystrybucja tras (statyczna, dynamiczna); - funkcja autentykacji podobnie jak dla protokoBu RIP; - [ledzenie wymienianych komunikatów; - przegldanie stanu interfejsów, ssiadów, baz danych rutera; - tworzenie list dystrybucyjnych. Dla procesu BGP: - definiowanie systemów autonomicznych; - blokowanie / uruchamianie procesów BGP; - ustalanie ssiednich speakerów; - ustalanie jakie trasy bd redystrybuowane i do jakich procesów; - filtrowanie ruchu zgodnie z okre[lon list; - przegldanie ruchu i statystyk zwizanych z procesem BGP; - definiowanie klastrów w celu realizacji techniki odzwierciedlania tras. 4. PrzykBadowa konfiguracja [rodowiska rutingu Poni|ej przedstawiona zostaBa przykBadowa konfiguracja [rodowiska, w którym uruchomione i przetestowane zostaBy procesy RIP, OSPF i BGP. 70 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego Rys.7. Konfiguracja [rodowiska testowego. Sie testowa zawiera trzy rutery o nazwach: p253gk, p253tm i Kokon oraz cztery obszary zdefiniowane na potrzeby protokoBu OSPF. Na rysunku zaznaczone s adresy portów ruterów (kart sieciowych zainstalowanych w [rodowisku Linux) oraz adresy IP sieci tworzcych obszary OSPF. Poni|ej omówiona zostanie konfiguracja ruterów p253tm i Kokon, czytelnikowi pozostawione jest (jako wiczenie) napisanie analogicznej konfiguracji dla rutera p253gk. Zawarto[ plików konfiguracyjnych zebra.conf dla ruterów p253tm i Kokon jest nastpujca: dla p253tm: dla Kokon: !zebra configuration file ! Zebra configuration saved from vty ! 2000/11/23 14:32:59 hostname zebra-p253nt hostname zebra-Kokon password z password z ip route 10.0.10.0/24 10.0.3.1 ip route 10.0.7.0/24 10.0.2.1 log file /var/log/zebra/zebra.log log file /var/log/zebra/zebra.log Biuletyn Instytutu Automatyki i Robotyki, 16/2001 71 T. Malinowski W plikach tych zamieszczone zostaBy podstawowe polecenia: - hostname  definiujce nazw rutera; - password  okre[lajce hasBo dla logujcego si z terminala operatora (administratora) rutera; - ip route  definiujce statyczn [cie|k (do sieci 10.0.10.0 dla p253tm i sieci 10.0.7.0 dla rutera Kokon; - log file  okre[lajce poBo|enie pliku zebra.log, gdzie umieszczane bd komunikaty zwizane z dziaBaniem procesu zebra. Podobnie jak dla menad|era zebra, w plikach konfiguracyjnych protokoBu RIP (ripd.conf), zawarte zostaBy jedynie wybrane polecenia. dla p253tm: dla Kokon: ! RIPd configuration file ! RIPd configuration file !hostname ripd-p253tm !hostname ripd-Kokon password z password z router rip router rip network 172.16.50.0/24 network 172.16.50.0/24 network 10.0.3.0/24 network 10.0.2.0/24 neighbor 172.16.50.126 neighbor 172.16.50.118 redistribute static redistribute static route 10.0.5.0/24 route 10.0.1.0/24 timers basic 30 150 120 timers basic 30 150 120 log file /var/log/zebra/ripd.log log file /var/log/zebra/ripd.log gdzie: - router rip  odblokowuje proces RIP na ruterze; - network  odblokowuje przyjmowanie komunikatów RIP z wyszczególnionej w poleceniu sieci; - neighbor  okre[la ssiada, z którym wymieniane bd tablice rutingu; - redistribute static  wymusza przekazywanie do ssiada informacji o trasie statycznej (zadeklarowanej w zebra.conf); - route  okre[la sie docelow, do której wiedzie droga przez dany ruter; - timers basic - ustala warto[ci krytyczne czasomierzy protokoBu RIP. Po wykonaniu czynno[ci konfiguracyjnych nale|y uruchomi proces zebra i ripd. Pierwszym krokiem na drodze do zarzdzania rutingiem z poziomu terminala jest zalogowanie si na wybranym ruterze. Poni|ej podany jest sposób zalogowania si do rutera uruchomionego na lokalnym ho[cie (ruter Kokon). 72 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego Wej[cie w tryb uprzywilejowany poprzedzone jest wydaniem polecenia  enable (na widocznym powy|ej ekranie polecenie en) wraz z odpowiednim hasBem dla administratora (je[li takie byBo ustawione w pliku konfiguracyjnym), w tym przypadku dla demona zebra. Wylistowana tutaj zostaBa lista komend, w du|ej mierze pokrywajcych si z komendami systemu IOS Cisco. Podobnie jak w systemie IOS mo|liwe jest wydawanie poleceD w formie skróconej (np. enable jest równowa|ne poleceniu en). Na wydruku poni|ej przedstawione s komendy dostpne z poziomu terminala po zalogowaniu si do demona ripd. Jak pamitamy prezentowany system jest zdekomponowany na kilka procesów dostpnych oddzielnie przez wirtualne terminale i odpowiednie porty. Biuletyn Instytutu Automatyki i Robotyki, 16/2001 73 T. Malinowski Administrator systemu mo|e skonfigurowa system edytujc odpowiednie pliki konfiguracyjne lub te| wykorzystujc opcj  configure , która daje mo|liwo[ konfigurowania wprost z linii poleceD terminala. Zasada ta dotyczy wszystkich omawianych tutaj procesów, jak równie| menad|era o nazwie zebra. Podany ekran pokazuje konfiguracj protokoBu RIP dla rutera o nazwie Kokon po wydaniu polecenia  show ip protocol z poziomu terminala demona ripd. Jak wida uaktualnienia RIP wysyBane s co 30 sekund (nastpne uaktualnienie zostanie wysBane za 7s), co okre[lone jest przez warto[ czasomierza aktualizacji. Domy[lna warto[ czasomierza bBdu zmieniona zostaBa ze 180s na 150s (zapis Timeout after 150 seconds), czasomierz usuwania 74 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego z domy[lnej warto[ci 270s zostaB ustawiony na 120s (garbage collect after 120seconds), co jest zgodne z konfiguracj w pliku ripd.conf. Przy konfiguracji protokoBu nie zastosowano |adnych reguB filtrowania dla pakietów z trasami napBywajcych do rutera i wychodzcych z niego. Zastosowana zostaBa (domy[lnie) wersja RIP 2 protokoBu. Podane zostaBy równie| adresy IP obsBugiwanych przez protokóB podsieci. Przypisana protokoBowi odlegBo[ administracyjna to 120. Warto[ redistribution metric równa 1 odpowiadajca kosztowi pojedynczego skoku (jeden ruter po[redni) na drodze do sieci docelowej. Ostatnia otrzymana aktualizacja od ssiada o adresie 172.16.50.118 miaBa miejsce 23s przed wylistowaniem informacji na temat konfiguracji protokoBu.  Show ip rip jest poleceniem umo|liwiajcym wylistowanie tras wymienianych przez proces RIP. Obok sieci docelowych podane s tutaj adresy nastpnego skoku, liczba skoków, zródBo informacji o danej trasie i czas ostatniej aktualizacji (jak dawno zapis byB aktualizowany). Poni|ej przedstawione s informacje na temat [cie|ek w sieci skompletowane przez rutery Kokon i p253tm po pewnym czasie dziaBania procesów RIP. W ka|dej chwili dostpna jest funkcja [ledzenia wymienianych pakietów. Operator rutera mo|e obejrze wysyBane w sie pakiety RIP sigajc do pliku ripd.log lub oglda je na ekranie (dokonujc odpowiedniego przekierowania strumienia komunikatów). Wymieniane w trakcie dziaBania Biuletyn Instytutu Automatyki i Robotyki, 16/2001 75 T. Malinowski protokoBu RIP komunikaty midzy ruterami p253tm i Kokon przedstawia poni|szy ekran. Oczywi[cie komunikaty te mog by filtrowane i zbierane w pliku logów (ripd.log). Zawarto[ takiego pliku jest bardzo cenna z punktu widzenia diagnozowania problemów w sieci wynikajcych z niewBa[ciwego skonfigurowania protokoBu rutingu. Kolejne pliki konfiguracyjne  ospfd.conf dotycz protokoBu OSPF uruchomionego na ruterach p253tm i Kokon obok dziaBajcych na nich procesach RIP. dla p253tm: dla Kokon: !OSPFd configuration file ! OSPFd configuration file !hostname ospfd-p253tm hostname ospfd-Kokon password z password zebra router ospf router ospf network 172.16.50.0/24 area 0 network 172.16.50.0/24 area 0 network 10.0.3.0/24 area 2 network 10.0.2.0/24 area 3 redistribute kernel redistribute kernel redistribute static redistribute static redistribute connected redistribute connected log file /var/log/zebra/ospfd.log log file /var/log/zebra/ospfd.log 76 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego Najwa|niejsze z poleceD to: - router ospf  uruchamiajce (odblokowujce proces OSPF) na danym ruterze; - network  okre[lenie adresów: dla obszaru zerowego i obszaru wBczanego przez ruter do szkieletu; - redistribute  wyspecyfikowanie rodzaju redystrybuowanych przez ruter tras (statycznych, kernelowych, adresów osigalnych bezpo[rednio przez interfejs rutera). Po skonfigurowaniu w zakresie podstawowym ruterów i uruchomieniu procesu ospfd rozpoczyna si etap wymiany komunikatów  odkrywajcych obecno[ ssiadów i elekcji rutera desygnowanego (DR-a) oraz zapasowego rutera desygnowanego (BDR-a). Komunikaty te mo|emy podglda ustawiajc [ledzenie pakietów protokoBu OSPF. Wynik [ledzenia uruchomionego na ruterze Kokon przedstawiony jest poni|ej. Polecenie  show ip ospf interface umo|liwia wgld w status interfejsów rutera, jak równie| obejrzenie stanu jaki ustaliB si po okresie wymiany pakietów  hello . Biuletyn Instytutu Automatyki i Robotyki, 16/2001 77 T. Malinowski W naszym przykBadzie ruterem desygnowanym wybrany zostaB ruter o adresie interfejsu 172.16.50.118 (p253-tm), a zapasowym ruter 172.16.50.126 (Kokon). Jak wida dla rutera Kokon protokóB OSPF dziaBa jedynie na interfejsie Bczcym go ze szkieletem sieci. Analogicznie przedstawia si stan rutera p253- tm. Sieci 10.0.3.0 i 10.0.2.0, przedstawione na rysunku 7 s sieciami  martwymi bez aktywnych wewntrznych ruterów. UzupeBnieniem tych informacji s dane na temat aktywno[ci interfejsów rutera dla kolejnych obszarów (polecenie  sh ip ospf ) oraz  show ip ospf database , przedstawiajcy peBen obraz na temat wymienianych przez ruter tras. 78 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego Wylistowane powy|ej dane zawieraj peBn informacj o trasach wiodcych do ka|dego obszaru (Router Links, Net Links) oraz trasach zgBaszanych do szkieletu wiodcych do innych sieci (External Links), które nie wchodz w skBad wymienianych tutaj obszarów OSPF tzw. trasach zewntrznych osigalnych przez dany ruter. Ka|da trasa opisywana jest przez jej adres IP (Link ID), ruter rozgBaszajcy t tras (ADV Router), wiek trasy (Age), numer sekwencyjny (Seq#), sum kontroln (CkSum), liczb interfejsów, na których uruchomiono OSPF w ruterze (Link count). Numer sekwencyjny u|ywany jest tutaj do wykrywania Bczy starych, zdublowanych lub spoza sekwencji ogBoszeD. Suma kontrolna, w zasadzie najwa|niejszy element opisujcy dan tras, w peBni j identyfikuje i jest wykorzystywana w procesie konfrontowania posiadanych danych z danymi rutera desygnowanego (zapasowego rutera desygnowanego). Jest to sposób na stwierdzenie, czy posiadane przez ruter dane s aktualne. Ostatnim konfigurowanym protokoBem byB protokóB BGP. ProtokóB BGP przeznaczony jest do wymiany tablic rutingu midzy ruterami stojcymi na granicy du|ych (zawierajcych powy|ej 50 ruterów) systemów autonomicznych. Uruchamianie go w tak maBym, realnym [rodowisku sieciowym byBoby posuniciem przesadnym. Pliki konfiguracyjne bgpd.conf ruterów p253-tm i Kokon przedstawione s poni|ej. Biuletyn Instytutu Automatyki i Robotyki, 16/2001 79 T. Malinowski dla p253tm: dla Kokon: ! BGPd configuration file ! BGPd configuration file !hostname bgpd-p253tm hostname bgpd-Kokon password z password z router bgp 3 router bgp 2 neighbor 172.16.50.126 remote-as 2 neighbor 172.16.50.118 remote-as 3 redistribute static redistribute static redistribute rip redistribute rip log file /var/log/zebra/bgpd.log log file /var/log/zebra/bgpd.log Niezbdne minimum to: - odblokowanie procesu bgp na ruterze  polecenie ruter bgp; - okre[lenie ssiada  polecenie neighbor; - okre[lenie rodzajów rozgBaszanych tras  polecenie redistribute. Podstawowym testem dziaBania procesu BGP jest wydanie polecenia  show ip bgp neighbors po zalogowaniu si do systemu z poziomu terminala dla demona bgpd (telnet Kokon 2605). Efekt wydania polecenia przedstawiony jest na ekranie poni|ej. Ostatnim testem na poprawno[ konfiguracji i dziaBania ruterów jest obejrzenie tablic rutingu i skonfrontowanie ich z wBasnymi oczekiwaniami. Po zalogowaniu si na ruterze z terminala zebry (telnet p253-tm 2601) systemowa tablica rutingu mo|e by wylistowana poleceniem  show ip route . Kolejne dwa zrzuty ekranu 80 Biuletyn Instytutu Automatyki i Robotyki, 16/2001 ProtokoBy rutingu dynamicznego przedstawiaj tablice rutingu ruterów p253tm i Kokon skompletowane po pewnym czasie dziaBania na nich trzech protokoBów: RIP, OSPF i BGP. Odniesienie otrzymanych wyników do konfiguracji sieci testowej (rysunek 7) pozostawia si czytelnikowi. Biuletyn Instytutu Automatyki i Robotyki, 16/2001 81 T. Malinowski 5. Podsumowanie Opracowanie stanowi wstp do badania najpopularniejszych obecnie protokoBów rutingu, wykorzystywanych zarówno w maBych (z niewielk liczb ruterów) sieciach LAN, jak i w du|ych systemach autonomicznych sieci Internet. Wybór protokoBu rutingu i jego wBa[ciwe skonfigurowanie jest ciekawym zadaniem projektowym. Przemy[lana konfiguracja sieci owocuje wysok wydajno[ci, a przede wszystkim jej niezawodno[ci dziaBania (cigB dostpno[ci najlepszych [cie|ek dla trasowanych pakietów). Znajomo[ tajników dziaBania protokoBów trasowania jest równie| kluczem do zabezpieczenia sieci przed nadmiernym ruchem o charakterze organizacyjnym i ruchem zwizanym z wszelkimi próbami niepowoBanego dostpu z zewntrz. Omawiane w pracy rozwizanie ma du|e walory poznawcze. Umo|liwia zapoznanie si z oprogramowaniem odpowiadajcym na poziomie funkcjonalnym oprogramowaniu ruterów Cisco, firmy nazywanej  szar eminencj Internetu , której wysokiej klasy produkty dominuj ostatnio rynek sprztu przeBczajcego i rutujcego. Literatura: [1] Ballew S. M.: Zarzdzanie sieciami IP za pomoc ruterów Cisco, Wydawnictwo RM, Warszawa 1998 [2] Rybaczyk P.: Podrcznik In|ynierii Internetu, Wydawnictwo PLJ, Warszawa 1999 [3] Slattery T., Burton B.: Zaawansowane trasowanie IP w sieciach Cisco, Wydawnictwo PLJ, Warszawa 2000 [4] Lewis C.: Routing Cisco TCP/IP dla profesjonalisty, Wydawnictwo PLJ, Warszawa 1999 [5] Malkin G.: RIP Version 2, RFC 2453 [6] Hedrick C. L.: Routing Information Protocol, RFC1058 [7] Moy J.: OSPF Version 2, RFC 2328 [8] Rekhter Y., Li T.: A Border Gateway Protocol 4 (BGP-4), RFC 1771 [9] Bates T., Chandra R., Chen E.: BGP Route Reflection - An Alternative to Full Mesh IBGP, RFC 2796 [10] GNU Zebra. Free routing software distributed under GNU General Public License - www.zebra.org [11] Ishiguro K.: Dokumentacja GNU Zebra - wersja html, http://www3.math.spbu.ru/~nformatycznych, 1999. Recenzent: dr in|. Janusz Furtak Praca wpBynBa do redakcji: 10.10.2001 82 Biuletyn Instytutu Automatyki i Robotyki, 16/2001

Wyszukiwarka

Podobne podstrony:
Protokoly routingu dynamicznego akademia cisco
Konfiguracja protokolow routingu statycznego i dynamicznego
02 Żydzi którzy napisali Protokoły Syjonu
2 Dynamika cz1
,Modelowanie i symulacja systemów, Model dynamiczny
metrologia cw 1 protokol
protokół różyca doc
Kinematyka i Dynamika Układów Mechatronicznych
wzory protokołów pomiarowych zap1102012 z1
C w6 zmienne dynamiczne wskazniki funkcji
Protokół Buhnera
Wzor protokolu OSP

więcej podobnych podstron