Rozdział 19.
Projektowanie trasowania dla sieci

W tym rozdziale:

• Podstawy trasowania

• Tworzenie struktury trasowania

• Trasowanie dynamiczne

W rozdziale 18. omówiono podział na podsieci i wydobywanie identyfikatora podsieci z adresu IP i maski podsieci. Teraz zobaczymy, jak można zastosować te mechanizmy. Kilka razy już kładliśmy nacisk na fakt, iż nie da się umieścić nieograniczonej liczby komputerów w jednym segmencie sieci — wobec tego musimy podzielić sieć na mniejsze, łatwiejsze do opanowania fragmenty.

Niniejszy rozdział omawia podstawy trasowania i wyniki dodawania coraz większej liczby segmentów do sieci. Do innych zagadnień omówionych tutaj należą: trasowanie klasowe i bezklasowe, maski podsieci o zmiennej długości i różne metody automatycznej wymiany informacji o trasach pomiędzy różnymi ruterami w sieci, zamiast ręcznej konfiguracji informacji.

Podstawy trasowania

Trasowanie (routing) jest procesem przesyłania informacji z sieci źródłowej do docelowej poprzez dowolne urządzenie, które posiada dwa lub więcej interfejsów sieciowych i stos IP. Inaczej mówiąc, urządzenie „przygląda się” każdemu odebranemu pakietowi i ustala, czy ten pakiet wędruje do sieci, do której dane urządzenie jest przyłączone fizycznie. Jeśli tak, to pakiet zostanie wysłany na dany interfejs lokalny. W przeciwnym razie ruter szuka trasy, której może użyć. Ogólnie mówiąc, ruter sprawdza, czy jeden z ruterów, z którym jest połączony, potrafi przesłać pakiet dalej.

Ten mechanizm jest kamieniem węgielnym trasowania i sieci z wyborem tras: rutery przesyłają pakiet po jednym przeskoku na raz (przeskok taki nazywany jest hopem), aż do osiągnięcia miejsca przeznaczenia. Sam ruter jest bardzo prostym urządzeniem. W rzeczywistości dowolne urządzenie, posiadające dwa lub więcej interfejsów sieciowych i warstwę protokołu IP, można zmusić do trasowania pakietów.

Załóżmy, że sieć została podzielona na dwie części (na potrzeby przykładu wybierzemy prosty podział na podsieci). Pierwsza sieć ma adres 10.10.2.0, zaś druga 10.10.56.0. W obu maska podsieci jest 255.255.255.0 (patrz rysunek 19.1).

Rysunek 19.1. Prosty przykład sieci

Jak widać, dwie sieci są rozdzielone ruterem, który posiada dwa interfejsy sieciowe; po jednym dla każdej sieci: 10.10.2.1 i 10.10.56.1. Gdy host, na przykład 10.10.2.51, próbuje wysłać pakiet do 10.10.2.53, wówczas warstwa internetowa z IP lokalnego hosta i maski podsieci otrzymuje ID sieci 10.10.2.0. Ponieważ host docelowy może mieć inną maskę podsieci, warstwa internetowa używa IP adresata i własnej maski podsieci (jedynej, którą zna) i uzyskuje prawdopodobny ID sieci hosta docelowego. W naszym przykładzie uzyskamy ID sieci 10.10.2.0, zgodny z własnym ID sieci nadawcy. Ponieważ identyfikatory sieci dla nadawcy i odbiorcy są takie same, IP rozpoznaje, że host docelowy jest lokalny, więc za pomocą protokołu ARP (Address Resolution Protocol — protokół rozwiązywania adresu) znajduje adres sprzętowy karty interfejsu sieciowego adresata i wysyła pakiet bezpośrednio do hosta.

Jak dotąd ruter nie brał udziału w transmisji i nie wystąpiło trasowanie. Gdyby adres IP adresata należał do drugiej podsieci, na przykład 10.10.56.52, wówczas ruter zostałby zaangażowany w transmisję. Ponownie IP i maska podsieci lokalnego hosta służą do ekstrakcji ID lokalnej podsieci — 10.10.2.0. Jednakże po nałożeniu lokalnej maski podsieci na IP adresata uzyskany zostanie ID sieci 10.10.56.0. Ten identyfikator nie jest zgodny z lokalnym, wobec czego pakiet trzeba będzie trasować. Proces trasowania zaczyna się w lokalnej stacji roboczej za pomocą tablicy tras.

Tablica tras

Trasowanie w rzeczywistości zaczyna się już w lokalnym komputerze, który posiada specjalną tablicę, zwaną tablicą tras. Jest ona tworzona przy każdym uruchomieniu systemu i służy IP do trasowania pakietów. W przypadku komputera lokalnego tablica tras zwykle zawiera wpisy lokalne i jeden wpis przesyłający cały pozostały ruch do lokalnego rutera. Poniżej przedstawiliśmy przykład tablicy tras, jaka może znajdować się w hoście 10.10.2.51:

Adres sieciowy Maska sieci Adres bramy Interfejs Metryka

0.0.0.0 0.0.0.0 10.10.2.1 10.10.2.51 1

10.10.2.0 255.255.255.0 10.10.2.51 10.10.2.51 1

10.10.2.51 255.255.255.255 127.0.0.1 127.0.0.1 1

10.255.255.255 255.255.255.255 10.10.2.51 10.10.2.51 1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

224.0.0.0 224.0.0.0 10.10.2.51 10.10.2.51 1

255.255.255.255 255.255.255.255 10.10.2.51 10.10.2.51 1

Na pierwszy rzut oka ta tablica może wyglądać na zagmatwaną, lecz tak naprawdę łatwo ją zrozumieć. Docelowy adres IP jest łączony z maską sieci, aby wydobyć ID sieci. Jeśli uzyskany ID sieci jest zgodny z docelową siecią, to znaleźliśmy trasę i możemy wysłać dane za pomocą lokalnego interfejsu sieciowego, wymienionego w kolumnie Interfejs, pod adres z kolumny Adres bramy.

W tablicy tras pierwszy wpis od góry to 0.0.0.0 zarówno w kolumnie Maska sieci, jak i w docelowym adresie sieciowym. Użycie tej maski z dowolnym adresem IP zawsze da jako sieć docelową 0.0.0.0. Umieszczenie tego wpisu na początku tablicy może wyglądać dziwnie, jednakże tablica tras jest czytana w odwrotnej kolejności (z dołu do góry). W tym przypadku system na początku sprawdza, czy pakiet jest wysłany na globalny adres rozgłoszeniowy (255.255.255.255), następnie sprawdza adres grupowy (224.0.0.0), a na koniec adres pętli zwrotnej (127.0.0.1).

Po sprawdzeniu tych adresów system wymienia adresy dla każdego interfejsu lokalnego (jeśli komputer posiada więcej kart sieciowych, wiersze te będą powtórzone dla każdego interfejsu). Dla każdego lokalnego interfejsu najpierw szuka adresu rozgłoszeniowego podsieci (.255), następnie wszelkich pakietów kierowanych do lokalnego hosta, a na koniec wszystkiego, co wychodzi do lokalnej podsieci. Sprawdzanie lokalnego adresu IP może wydać się nadmiarowe, biorąc pod uwagę, że system już sprawdził, iż pakiet przeznaczony jest dla sieci lokalnej; jednakże system z wieloma kartami sieciowymi wymaga sprawdzania lokalnych interfejsów, aby pakiety odebrane na jednym interfejsie (gdzie zostaną porównane z IP i maską podsieci tego interfejsu) mogły być wysłane z innego interfejsu.

Wpis 0.0.0.0, będący tzw. trasą domyślną (default route), wychwytuje wszystko i pojawia się tylko wtedy, gdy system posiada skonfigurowaną bramę domyślną. Jeśli nie zostanie znaleziona żadna trasa podczas porównywania przez system docelowego adresu IP z każdą maską sieci w tablicy tras, to trasa domyślna posłuży do wysłania pakietu do skonfigurowanego rutera.

Wracając do naszego przykładu (w którym 10.10.2.51 chce skomunikować się z 10.10.56.52), system lokalny używa pokazanej przed chwilą tablicy tras, aby ustalić kolejny przeskok (hop). W tym przypadku zostanie użyta trasa domyślna, a system za pomocą protokołu ARP znajdzie adres sprzętowy karty 10.10.2.1. Pakiet zostanie następnie przesłany do hosta o adresie IP 10.10.2.1, który w naszym przypadku jest ruterem.

Ruter odbierze pakiet i porówna go z adresem IP i maską podsieci lokalnego interfejsu. W tym przypadku ruter porówna pakiet skierowany do 10.10.56.52 z adresem IP 10.10.2.1. za pomocą maski podsieci 255.255.255.0. Podobnie jak przed chwilą, wynik porównania oznacza, że host docelowy jest zdalny (dla danego interfejsu) i zmusi ruter do sprawdzenia swojej tablicy tras.

Adres sieciowy Maska sieci Adres bramy Interfejs Metryka

10.10.2.0 255.255.255.0 10.10.2.1 10.10.2.1 1

10.10.2.1 255.255.255.255 127.0.0.1 127.0.0.1 1

10.255.255.255 255.255.255.255 10.10.2.1 10.10.2.1 1

10.10.56.0 255.255.255.0 10.10.56.1 10.10.56.1 1

10.10.56.1 255.255.255.255 127.0.0.1 127.0.0.1 1

10.255.255.255 255.255.255.255 10.10.56.1 10.10.56.1 1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

224.0.0.0 224.0.0.0 10.10.2.51 10.10.2.51 1

255.255.255.255 255.255.255.255 10.10.2.51 10.10.2.51 1

W tym przykładzie IP odkryje, że trasa 10.10.56.0 współpracuje z maską 255.255. 255.0. System prześle więc pakiet do bramy 10.10.56.1 (do siebie samego), aby dostarczyć go do 10.10.56.52. Do znalezienia adresu karty sieciowej hosta końcowego posłuży protokół ARP i pakiet zostanie dostarczony.

Podsumowując proces: źródłowy host na podstawie swojego adresu IP i maski podsieci oraz docelowego adresu IP ustala, czy adresat jest lokalny. Jeśli tak, pakiet zostaje przesłany bezpośrednio do hosta pod jego adres sprzętowy (określony za pomocą ARP). Jeśli adresat nie jest lokalny, wówczas nadawca wyszukuje w swojej tablicy tras trasę do niego. Jeśli trasa zostanie znaleziona, pakiet będzie wysłany do bramy skonfigurowanej dla tej trasy, na podstawie jej adresu sprzętowego (ponownie ustalonego przez ARP).

Brama odbiera pakiet i w ten sam sposób porównuje adres docelowy ze swoim adresem IP i maską podsieci dla interfejsu, na którym pakiet został odebrany. Jeśli pakiet jest lokalny (co świadczy o wystąpieniu błędu gdzieś po drodze, ponieważ host już dokonał tego samego porównania), pakiet zostaje wysłany do hosta docelowego z wykorzystaniem jego adresu sprzętowego. Jeśli porównanie wykaże, iż adresat jest zdalny (powinien być), do ustalenia kolejnego hopu zostaje wykorzystana tablica tras bramy. Jeśli kolejny hop jest lokalny dla dowolnego z interfejsów bramy, pakiet zostaje przesłany do kolejki dla tego interfejsu i wysłany bezpośrednio do celu za pomocą adresu sprzętowego. Jeśli okaże się, że trasa nie jest lokalna, brama przesyła pakiet dalej. W przypadku braku trasy ruter zwraca do nadawcy pakietu komunikat „upłynął limit czasu żądania”, „host docelowy nie został znaleziony” lub „host docelowy jest nieosiągalny” za pomocą protokołu ICMP (Internet Control Message Protocol).

Budowanie tablicy tras

Czytelnik może zastanawiać się, skąd bierze się tablica tras. Czy jest ładowana z pliku? Czy jest wyliczana? Czy użytkownik musi coś zrobić, aby utworzyć tablicę tras? Odpowiedź na wszystkie trzy pytania jest twierdząca.

Lecz zacznijmy po kolei. W przykładzie używanym w tym podrozdziale trasowanie funkcjonowało, ponieważ ruter był podłączony fizycznie do każdej sieci i mógł dzięki temu budować swoją tablicę tras na podstawie tych sieci. Na rysunku 19.2. przedstawione zostały dwa rutery i trzy sieci, zaś żaden z ruterów nie jest bezpośrednio podłączony do wszystkich trzech sieci. Oznacza to, że ani jeden, ani drugi ruter nie może zbudować tablicy tras zawierającej wszystkie trzy sieci.

Rysunek 19.2. Przykład rozbudowy prostej sieci

Rysunek 19.2 przedstawia dwa rutery, A i B. Ruter A „wie” o sieciach 10.10.2.0 i 10.10.56.0, ponieważ posiada fizyczne połączenie z każdą z nich. Podobnie, ruter B „wie” o sieciach 10.10.56.0 i 10.10.59.0.

Gdy host 10.10.2.50 próbuje skomunikować się z hostem 10.10.59.51, mamy problem. System sprawdza kombinację adresów IP i maski podsieci i ustala, że adresat jest zdalny. Dzięki wpisowi bramy domyślnej (0.0.0.0) w tablicy tras, pakiet zostanie wysłany do skonfigurowanego rutera (A). Ten również sprawdza IP i maskę podsieci na interfejsie, na którym odebrał pakiet i stwierdza, że ma on zostać dostarczony do hosta zdalnego względem tego interfejsu. Następnie sprawdza swoją tablicę tras, a ponieważ zawiera ona jedynie informacje zebrane z lokalnych interfejsów, nie znajdzie trasy. Ruter A nie „wie” nic o sieci 10.10.59.0, ponieważ nie ma z nią fizycznego połączenia. Na skutek tego zwraca komunikat „host docelowy jest nieosiągalny”.

Ruter A potrzebuje jakiejś metody przekazywania pakietu do rutera B. Najprostszym sposobem jest skonfigurowanie rutera A tak, by przesyłał wszelkie pakiety o nieznanych sobie adresach do rutera B — inaczej mówiąc, użycie rutera B jako bramy domyślnej dla rutera A. Wówczas ruter A mógłby użyć trasy domyślnej, aby przesłać pakiet do rutera B (ponieważ nie zna innej trasy). Ruter B „zna” sieć 10.10.59.0, ponieważ jest z nią fizycznie połączony. W wyniku tego ruter B dostarczy pakiet.

Pozostaje jednak pewien problem. Załóżmy, że host 10.10.2.50 wysyła żądanie echa (ping). Pakiet dociera do 10.10.59.1 i host ten zamierza teraz odesłać odpowiedź echa z powrotem do 10.10.2.50. Host dokonuje porównania, odkrywa że adresat jest zdalny, znajduje pierwszą bramę domyślną i wysyła pakiet do rutera B. Ten kontroluje pakiet na lokalnym interfejsie i ustala, że jest zdalny; zgodnie z tym sprawdza tablicę tras i zwraca do 10.10.59.1 komunikat „host docelowy jest nieosiągalny”. Host docelowy nie może zostać osiągnięty, ponieważ ruter B nie „wie” o sieci 10.10.2.0 więcej, niż ruter A wiedział o sieci 10.10.59.0. Wobec tego najlepszym sposobem, by umożliwić ruterowi B przekazanie pakietu do rutera A, jest skonfigurowanie A jako bramy domyślnej w ruterze B. Rozwiązanie to jest łatwe do wykonania, jednakże nie będzie działać, jeśli dodamy jeszcze jedną sieć. Rysunek 19.3 pokazuje potencjalne komplikacje.

Rysunek 19.3. Dodajemy kolejną sieć

Statyczny wybór trasy

Wraz ze wzrostem rozmiarów sieci metoda bramy domyślnej przestaje się sprawdzać. Ponieważ tylko jeden wpis bramy domyślnej ma znaczenie, możemy wprowadzić kilka wpisów — lecz tylko pierwszy, który zostanie znaleziony przez system operacyjny, zostanie użyty, o ile nie jest nieczynny. W tym przypadku możemy poradzić sobie z siecią za pomocą rutera z wieloma interfejsami (na przykład czterema), aby wszystkie sieci były dla niego lokalne; staje się to jednak trudne, gdy musimy połączyć 50 lub 60 podsieci.

Musimy „powiedzieć” ruterom o istnieniu innych sieci, z którymi nie są bezpośrednio połączone. Możemy to uczynić, dodając statyczne trasy do każdego rutera, aby rozpoznawał, gdzie wysłać pakiety przeznaczone dla nieznanych sieci. Jak widać na rysunku 19.3, ruter A „zna” sieci 10.10.2.0 i 10.10.56.0. Możemy dodać informacje o 10.10.59.0 i 10.10.99.0, mówiące ruterowi A, aby wysyłał adresowane do nich pakiety do rutera B. Zasadniczo musimy dodać następujące wiersze do tablicy tras:

Adres sieciowy Maska sieci Adres bramy Interfejs Metryka

10.10.59.0 255.255.255.0 10.10.56.2 10.10.56.1 2

10.10.99.1 255.255.255.0 10.10.56.2 10.10.56.1 2

Jeśli dodamy te wiersze do tabeli tras w ruterze A i odpowiednie trasy w pozostałych dwóch ruterach, informacje będą mogły przepływać przez całą sieć. W małych organizacjach jest to metoda preferowana, ponieważ nie angażuje dodatkowego ruchu w sieci na wzór dynamicznego trasowania. Jedynym problemem jest konieczność przeróbek wszystkich statycznych tras, jeśli konfiguracja sieci ulegnie zmianie.

Dodanie trasy jest w większości systemów operacyjnych prostą czynnością. Praktycznie wszystkie systemy operacyjne używają do tego celu polecenia route. Podstawowe parametry sterujące tego polecenia są następujące:

• print — wyświetla tablicę tras,

• add — tworzy statyczny wpis w tablicy tras,

• delete — usuwa wpis z tablicy tras,

• modify — zmienia istniejącą trasę,

• flush — usuwa wszystkie trasy z tablicy i przeładowuje z pliku lub rejestru.

Aby dodać trasy potrzebne w ruterze A do systemu Windows, należy wpisać:

route add 10.10.59.0 mask 255.255.255.0 10.10.56.2

route add 10.10.99.0 mask 255.255.255.0 10.10.56.2

W systemie Linux polecenia te będą wyglądać następująco:

route -A inet add -net 10.10.59.0 netmask 255.255.255.0 gw 10.10.56.2

route -A inet add -net 10.10.59.0 netmask 255.255.255.0 gw 10.10.56.2

Te polecenia dodają wymagane trasy w komputerze dla używanej właśnie konfiguracji. Jednakże jeśli system zawiesi się i będzie wymagał przeładowania, trasy zostaną utracone. Warto więc zapisać trasy w pliku (w środowisku uniksowym) lub w Rejestrze (w systemach Windows).

Wraz ze wzrostem rozmiarów sieci rośnie też liczba ruterów. Prędzej czy później dojdziemy więc do punktu, w którym ręczne aktualizacje ruterów nie będą możliwe i trzeba będzie znaleźć jakąś metodę automatycznej aktualizacji tablic tras. To zagadnienie zostanie omówione w jednym z kolejnych podpunktów, dotyczącym dynamicznego wyboru tras.

Tworzenie struktury trasowania

Omówiliśmy już podstawy trasowania, więc pora skierować dyskusję na fizyczny rozkład sieci. Typ używanej sieci fizycznej i wymagania dotyczące wydajności, omówione w rozdziale 18., również wchodzą w grę przy tworzeniu sieci. W istocie czynniki te są ściśle ze sobą powiązane.

Maski podsieci, które omówiliśmy w rozdziale 18., będą używane jako podstawowe maski dla klientów w podsieciach. Teraz musimy połączyć ze sobą wszystkie klienty za pomocą wybranego rodzaju sprzętu sieciowego, aby mogły komunikować się ze sobą. Oznacza to planowanie użycia koncentratorów lub przełączników do utworzenia topologii magistrali lub jednostek dostępu do stacji wieloterminalowych (MAU), aby utworzyć pierścień.

Ponieważ większość Czytelników zastosuje Ethernet, który jest topologią magistrali, skoncentrujemy się na tej właśnie topologii. Użytkownicy sieci Token Ring mogą, jak pamiętamy, do segmentu przyłączyć więcej hostów, niż jest w stanie obsłużyć Ethernet. W rozdziale 18. przedstawiliśmy podstawowy wzór do wyliczenia, ile hostów może zostać podłączonych do podsieci.

Łączenie podsieci

Jak połączyć ze sobą podsieci, aby trasowanie nadal funkcjonowało? Narzucającą się metodą (użytą w poprzednich przykładach) jest doczepianie kolejnych podsieci na koniec sieci logicznej (podsieć — ruter — podsieć), aż uzyskamy liczbę podsieci wystarczającą dla liczby posiadanych użytkowników (patrz rysunek 19.4).

Rysunek 19.4. Szeregowe łączenie podsieci

Ta metoda jest prosta i łatwa do zaimplementowania. Gdy jednak użytkownicy muszą komunikować się z innymi, oddalonymi o kilka hopów, rutery mogą zostać mocno obciążone. Jeśli którykolwiek z nich zawiedzie, może to mieć wpływ na całą sieć, ponieważ struktura nie jest nadmiarowa, a serwery nie są skoncentrowane.

Kolejnym oczywistym rozwiązaniem jest rozmieszczenie wszystkich sieci dookoła centralnego rutera. Równie łatwo wyobrazić sobie taką sieć, a wszystkie hosty powinny być w stanie łatwo komunikować się ze sobą (patrz rysunek 19.5).

Rysunek 19.5. Podsieci rozmieszczone dookoła centralnego rutera

Centralny ruter dobrze sprawdza się w małych biurach. W takiej strukturze możemy też łatwo zapewnić nadmiarowość, dodając w centrum drugi ruter. Jedynym problemem jest duża objętość danych, przepływających przez jeden ruter lub parę ruterów. A jeśli nie zastosujemy zapasowego rutera, sieć będzie posiadać pojedynczy punkt awarii.

Struktura z centralnym ruterem to konstrukcja pozwalająca rozbudowywać sieć. Jeśli wyznaczymy jedną z podsieci z rysunku 19.5 do roli „szkieletu”, otrzymamy ruter łączący trzy podsieci z siecią szkieletową. Rozbudowując sieć, przyłączymy kolejny ruter do sieci szkieletowej, a następnie dołączymy podsieci klienckie do tego rutera (patrz rysunek 19.6).

Rysunek 19.6. Wykorzystanie ruterów do podłączenia podsieci klienckich do sieci szkieletowej

Rysunek 19.6 przedstawia dość typowy projekt, używany w wielu sieciach. Wspólne serwery (na przykład serwer pocztowy) są zwykle przyłączone do sieci szkieletowej, zaś serwery klienckie (serwery plików i drukowania) mogą być przyłączone do podsieci razem z klientami. Awaria pojedynczego rutera nie wpływa na całą sieć i jest dość miejsca na rozwój. Patrząc na rysunek 19.6 przypomnijmy sobie obliczenia z rozdziału 18., gdzie każda z podsieci mogła pomieścić 30 lub 126 komputerów. W dwunastu podsieciach może pracować 360 użytkowników, a maksymalnie 1512. Dodawanie kolejnych użytkowników nie jest trudne; wystarczy dołączyć kolejny ruter i trzy kolejne podsieci lub przyłączyć 4 do 8 podsieci do każdego rutera.

Taka struktura jest bardzo elastyczna; jednakże objętość danych, z jaką może poradzić sobie sieć szkieletowa, jest ograniczona (nawet jeśli jest zbudowana w technice FDDI). Możemy zmniejszyć ten ruch, przenosząc więcej serwerów do podsieci klienckich i zapewniając, by użytkownicy udostępniający sobie nawzajem dane i komunikujący się ze sobą byli podłączeni do jednej podsieci, a przynajmniej do jednego rutera.

Prędzej czy później trzeba będzie jednak przekroczyć limit ruchu sieciowego, z jakim potrafi uporać się pojedyncza sieć szkieletowa. Można to zrobić, dzieląc szkielet na części i konfigurując trasowanie pomiędzy nimi. Prawdopodobnie nasza sieć i tak już posiada więcej szkieletów, ponieważ typowe sieci obejmują więcej niż jedną lokalizację, z osobną siecią szkieletową w każdej lokalizacji.

Maski podsieci o zmiennej długości

W strukturach posiadających jedną sieć szkieletową problemem jest ruch sieciowy. Jeśli wszystkie serwery podłączone są do jednego szkieletu lub użytkownicy intensywnie ze sobą współpracują, sieć szkieletowa będzie porządnie obciążona. Maski podsieci o zmiennej długości (VLSM — Variable Length Subnet Masking), zdefiniowane w RFC 1817, są rozwiązaniem pozwalającym tworzyć kilka poziomów sieci szkieletowej, a co za tym idzie, kilka różnych miejsc, w których dane mogą przechodzić z jednej sieci do drugiej. Implementacja VLS jest jednakże trudna, ponieważ w różnych częściach sieci mamy do czynienia z różnymi maskami podsieci.

Na potrzeby wyjaśnienia tego zagadnienia rozważmy maskę podsieci 255.255.255.224 jako opcjonalną maskę podsieci dla naszych klientów. Oznacza to, że chcemy ograniczyć każdą podsieć do 30 adresów IP, czyli 29 komputerów i interfejsu rutera. Możemy więc do budowania sieci wykorzystać 24-portowe przełączniki. Załóżmy dodatkowo, że stosujemy system Linux na potrzeby niskopoziomowych ruterów, i że każdy z nich będzie obsługiwał cztery karty sieciowe. Wobec tego kolejne podsieci będą miały adresy .0, .32, .64 i .96. Interfejsami ruterów będą przypuszczalnie pierwsze adresy IP z każdego segmentu — .1, .33, .65 i .97. Aby połączyć się z dużą siecią, potrzebne będzie jedno połączenie, więc wykorzystajmy podsieć .0. Rysunek 19.7 pokazuje, jak taki system może wyglądać.

Mamy teraz konfigurację, w której cały ruch do sieci.0, .32, .64 lub .96 będzie musiał przejść do .1. Dodajmy pozostałe oktety, żeby nasze adresy wyglądały bardziej normalnie. Cały ruch do podsieci 10.10.10.0, 10.10.10.32, 10.10.10.54 i 10.10.10.96 musi być kierowany na interfejs 10.10.10.1. Ruter ten następnie prześle do podsieci przeznaczone dla nich dane. Oznacza to jednak, że wszystkie dane dla adresów IP od 10.10.10.1 do

Rysunek 19.7. Ruter łączący cztery podsieci

10.10.10.127 muszą przejść przez ten ruter. Wprawdzie dla trzech klienckich podsieci maską podsieci musi być 255.255.255.22, lecz dla interfejsu łączącego je z większą siecią możemy użyć w masce sieci 255.255.255.128 lub mniej bitów.

W tym rozdziale używamy masek podsieci, lecz Czytelnik może również spotkać się z notacją /liczba_bitów, która jest łatwiejsza do czytania, gdy się już do niej przyzwyczaimy. Na przykład, adres 10.10.10.0 z maską podsieci 255.255.254.0 będzie zapisany jako 10.10.10.0/23.

Wykorzystanie takiego schematu adresowania oznacza, że inny ruter może posiadać adres 10.10.10.129 i obsługiwać ruch dla trzech innych podsieci. W istocie, na rysunku 19.8 widać, że jeśli użyjemy maski podsieci 255.255.254.0, będziemy mogli połączyć ze sobą jeszcze więcej ruterów.

Zbudowaliśmy więc strukturę sieci szkieletowej z własnymi maskami podsieci. Duże osiągnięcie, prawda? No cóż, jeśli przyjrzymy się dokładnie adresom na górze rysunku 19.8, zauważymy, że każda z tych dwunastu sieci może być opisana jako sieć 10.10. 10.0 z maską 255.255.254.0. Oznacza to, że możemy potraktować całą strukturę z rysunku 19.8 jako pojedynczy węzeł i powielić kilka razy, tworząc większą sieć. Rysunek 19.9 przedstawia następny poziom hierarchii.

Stosowanie masek o zmiennej długości wymaga oczywiście więcej pracy podczas planowania, zaczynając od decyzji o maksymalnej liczbie hostów. Jednakże skorzystanie z VLSM niesie ze sobą kilka korzyści:

• Możemy umieścić serwery na dowolnym poziomie hierarchii, dzięki czemu będą bliżej użytkowników.

• Możemy przydzielać oddziałom lub lokalizacjom bloki adresów o różnych wielkościach, zależnie od potrzeb.

Rysunek 19.8. Grupa czterech ruterów przyłączająca 12 podsieci

Rysunek 19.9. Trzy poziomy hierarchii w schemacie VLSM

• Zredukujemy ruch sieciowy dochodzący aż do sieci szkieletowej.

Czytelnicy pracujący w środowisku Windows powinni pamiętać, że Windows NT 4.0 i starsze systemy operacyjne nie mogą używać VLSM. Jest to związane ze sposobem, w jaki te systemy operacyjne porządkują wpisy w tablicach tras. Aby móc zastosować VLSM, wpisy o długich maskach podsieci muszą być sprawdzane w pierwszej kolejności.

Podłączanie odległych biur

Sposób podłączenia odległych jednostek będzie zależeć od ogólnego schematu, według którego zbudowaliśmy swoją sieć. Należy pamiętać o kilku podstawowych zasadach:

• Każde biuro powinno posiadać ciągły blok adresów. Ułatwi to trasowanie pomiędzy biurami.

• Jeśli połączenie używa interfejsu wyboru trasy na żądanie (dial-on-demand), trzeba będzie dodać dla niego trasy statyczne.

• Pomiędzy dwoma końcami łącza komunikacyjnego trzeba uwzględnić podsieć. W przypadku połączenia dwupunktowego może to być podsieć fałszywa.

• Powinniśmy posiadać połączenie zapasowe na wypadek awarii głównego połączenia. Dla typowego ruchu połączenie zapasowe może być typu L2TP (lub PPTP w środowisku Microsoftu).

Ogólnie mówiąc, jeśli używamy centralnego rutera w małej sieci, ruter wychodzący powinien być podłączony do podsieci zawierającej zasoby potrzebne zdalnym użytkownikom, jak na rysunku 19.10.

Rysunek 19.10. Ruter łączący dwa biura w prostej sieci

Jeśli sieć jest zbudowana na podstawie sieci szkieletowych, w każdym biurze należy utworzyć szkielet i połączyć rutery tworzące łącze ze szkieletami w każdym biurze. W implementacji VLSM możemy oderwać część przestrzeni adresowej potrzebną dla zdalnego biura i dodać ruter na odpowiednim poziomie. Rysunek 19.11 przedstawia przykład takiej architektury.

Rysunek 19.11. Łącze komunikacyjne w implementacji VLSM

Dynamiczny wybór tras

Jak pokazaliśmy wcześniej, rutery używają tablic tras do ustalania, gdzie przekazać każdy pakiet wymagający przesłania dalej. Oznacza to, że tablica tras w każdym ruterze musi zawierać wszystkie informacje niezbędne, by znaleźć następny hop do dowolnego systemu w sieci. W przypadku małych sieci możemy to osiągnąć, wprowadzając ręcznie trasy statyczne w ruterach. Dla sieci dużych — lub zmieniających się często — ręczne konfigurowanie niekoniecznie jest dobrym rozwiązaniem.

W sieciach dużych lub dynamicznych zwykle używać będziemy protokołu dynamicznego wyboru tras, w którym ruter wymienia swoje informacje o trasach z innymi ruterami w sieci. Dostępnych jest kilka protokołów wyboru tras, przyjrzymy się czterem z nich:

• IRD (Router Discovery z protokołu ICMP)

• RIP (Routing Information Protocol)

• IGRP (Internet Gateway Routing Protocol)

• OSPF (Open Shortest Path First)

Jednym z problemów z dużymi sieciami TCP/IP jest to, iż różne grupy w obrębie organizacji (lub nawet w różnych organizacjach) zarządzają różnymi obszarami sieci. Dla prostoty sieci TCP/IP są zwykle dzielone na systemy autonomiczne (AS — Autonomous System). Każdy system autonomiczny może stosować do zarządzania trasami dla bram wewnętrznych osobny protokół trasowania z rodzaju IGP (Interior Gateway Protocol — wewnętrzny protokół bramowy). IGP odpowiada za znajdowanie wszystkich bram przez pozostałe w obrębie systemu autonomicznego, jednakże IGP nie pozwalają na wymianę informacji o trasach pomiędzy różnymi systemami autonomicznymi. Do IGP należą protokoły RIP i IGRP, które służą do wzajemnego udostępniania informacji o trasach wewnątrz systemu autonomicznego.

Gdy chcemy wymieniać informacje pomiędzy różnymi systemami autonomicznymi, potrzebny jest zewnętrzny protokół bramowy (EGP — Exterior Gateway Protocol). Do pewnego stopnia może posłużyć do tego IGRP, lecz takie protokoły, jak OSPF są lepsze, ponieważ zostały zaprojektowane specjalnie w tym celu.

ICMP Router Discovery

Router Discovery z protokołu ICMP tak naprawdę nie jest protokołem wyboru trasy. Jest narzędziem, za pomocą którego host znajduje lokalną bramę domyślną, jeśli nie jest dla niego skonfigurowana ręcznie. IRD wykorzystuje dwa polecenia protokołu ICMP (Router Discovery — wykrycie rutera i Router Advertisement — ogłoszenie rutera), pozwalając klientowi wykryć ruter w swojej podsieci.

Ogłaszanie rutera

Rutery używające IRD okresowo ogłaszają swoją obecność w sieci: albo za pomocą adresu grupowego 224.0.0.1, albo za pomocą rozgłoszeń sieciowych pod adresem 255. 255.255.255. Gdy przychodzi na to czas (zwykle co 7 - 10 minut), ruter ogłasza na wszystkich lokalnych interfejsach adresy IP tych interfejsów. Podaje dodatkowo wartość preferencji, aby w przypadku obecności kilku ruterów klient wybrał ten o najwyższej wartości (liczbie) preferencji. Liczba ta jest stosowana, by dać administratorom kontrolę nad tym, który ruter będzie standardowo używany przez klienty.

Ogłoszenia zawierają również czas życia (TTL), który określa, jak długo klient będzie miał prawo korzystać z rutera. Czas ten powinien być dłuższy od okresów pomiędzy ogłoszeniami — domyślnie wynosi 30 minut.

Wykrycie rutera

Wykrycie rutera następuje zwykle, gdy host usiłuje połączyć się z systemem spoza własnej podsieci niedługo po swoim uruchomieniu (do 7 - 10 minut). Jeśli host otrzymał już ogłoszenie rutera, nie musi dokonywać wykrycia. Jeśli jednak ruter w podsieci ulegnie awarii lub klient musi natychmiast połączyć się ze zdalną siecią, może wysłać komunikat Route Discovery.

Ruter musi być tak skonfigurowany, aby pozwalał na wykrycia oraz aby używał 255. 255.255.255 jako adresu docelowego lub 224.0.0.2 jako adresu grupowego. Rutery obsługujące IRD dołączają się do grupy pod tym adresem i wysyłają komunikat Router Announcement (ogłoszenie rutera), gdy odbiorą żądanie Router Discovery. Nie wszystkie systemy operacyjne obsługują IRD (nawet w roli klientów). Na przykład, starsze klienty Microsoftu były niezdolne do wykrywania ruterów.

Jeśli nasza sieć ulega częstym zmianom i nie planujemy stosowania DHCP, IRD może być przydatnym protokołem. W większości przypadków jednak nie powinien być implementowany w środowisku przedsiębiorstwa.

Protokół RIP

Routing Information Protocol (RIP), zdefiniowany w standardzie internetowym STD 34, dobrze spełnia swoje zadania jako instrument, który daje ruterom możliwość dynamicznej wymiany informacji o trasach, w miarę zmian warunków w sieci. Istnieją dwie wersje RIP: 1. i 2. Wersja pierwsza jest implementowana już w bardzo niewielu miejscach, lecz warto się jej przyjrzeć, gdyż stanowi podstawę wersji 2.

Wersja 1.

Jak pamiętamy z podrozdziału dotyczącego tablic tras, na wpis składa się kilka elementów:

• docelowa sieć lub host,

• maska sieci,

• interfejs,

• brama,

• metryka.

Większość tych elementów powinna już być znajoma. Jeśli wynikiem jest docelowa sieć lub host, dane są wysyłane do interfejsu w celu dostarczenia do bramy. Należy zdać sobie sprawę, iż docelowy adres IP jest zestawiany z każdą maską sieci. Różne protokoły wyboru trasy używają metryki do zapisywania różnych wartości. W przypadku protokołu RIP metryka oznacza liczbę ruterów, przez które musi przejść pakiet.

Powód stosowania metryki jest stały — służy ona do ustalenia najlepszej trasy do zdalnej sieci, a więc do zdalnego hosta. Gdy mamy do wyboru ścieżkę zawierającą dziesięć ruterów i ścieżkę złożoną z zaledwie czterech, wybierzemy tę drugą. Rysunek 19.12 przedstawia prosty przykład sieci.

Rysunek 19.12 przedstawia cztery wewnętrzne podsieci z 24-bitowymi maskami podsieci. W trasowanie zaangażowane są trzy rutery. Klienty w sieci 10.10.4.0 mogą mieć spore kłopoty ze skontaktowaniem się z klientami z sieci 10.10.2.0. Zakładając, że rutery obsługują protokół RIP, i że zaczynamy od rutera D, proces dynamicznego udostępniania tras za pomocą RIP przebiega następująco:

Rysunek 19.12. Udostępnianie informacji o trasach za pomocą protokołu RIP w wersji 1.

1. Ruter D „zna” sieci 10.10.4.0 i 10.10.3.0, więc w odpowiednich odstępach czasu (domyślnie 30 sekund) rozgłasza swoją tablicę tras.

2. Ruter C odbiera rozgłoszenie i sprawdza zawarte w nim trasy.

3. Ruter C zwiększa wszystkie metryki w rozgłoszeniu o wartość metryki dla interfejsu, na którym odebrał rozgłoszenie (domyślnie o 1).

4. Ruter C sprawdza trasy. Znajduje trasę do sieci 10.10.4.0 o metryce równej dwa, której nie rozpoznał, więc dodaje trasę do tablicy. Oprócz tego znajduje trasę do 10.10.3.0, lecz tę posiada już w swojej tablicy tras. Ponieważ posiada dwie trasy do tej samej sieci, porównuje ich metryki. W przypadku trasy do 10.10.3.0 ruter ustala, że posiadana już przez niego trasa ma metrykę o jeden niższą od odebranej w rozgłoszeniu. Ponieważ metryki tras z rozgłoszeń są zawsze zwiększane o jeden przed porównaniem tras, trasy do sieci lokalnej zawsze wygrywają z ogłaszanymi przez sąsiadujący ruter.

5. Ruter C w odpowiedniej porze rozgłasza trasy które „zna”, łącznie z tymi, które właśnie „poznał”.

6. Ruter B otrzymuje rozgłoszenie i aktualizuje swoje informacje, dodając trasy dla 10.10.4.0 i 10.10.3.0. Trasa dla 10.10.1.0 nie zostaje dodana, ponieważ istnieje już trasa lokalna.

Na tym etapie wszystkie rutery „wiedzą” o sieci 10.10.4.0; ruter B również wyśle rozgłoszenie, aktualizując dane rutera C. Ten z kolei przez rozgłoszenie zaktualizuje dane rutera B. Teraz wszystkie rutery znają wszystkie trasy, a sieć jest w stanie zbieżności. Niestety RIP nie posiada tych informacji, więc dalej powtarza rozgłoszenia co 30 sekund. Transmisje te mogą zająć trochę pasma, zwłaszcza jeśli sieć zawiera więcej ruterów.

Z protokołem RIP są, poza ciągłym rozgłaszaniem, jeszcze inne problemy. Bardzo poważnym problemem jest wielkość, jaką mogą przybrać pakiety rozgłoszeń. Załóżmy, na przykład, że mamy użyć protokołu RIP w Internecie. Jeśli ruter w San Diego w Kalifornii rozgłosi pakiet RIP, a informacje będą przesyłane i uzupełniane od rutera do rutera, jak to rozgłoszenie będzie wyglądać w Glasgow w Szkocji? Oczywiście skumulowane po drodze informacje, które dotrą na drugi koniec świata, będą gigantyczne. Aby zapobiec niszczeniu sieci przez RIP, projektanci wbudowali mechanizm zabezpieczający. Żaden ruter nie może mieć metryk wyższych od 15, co ogranicza efektywne rozmiary sieci, w której można zastosować protokół RIP.

Reakcja na zmiany warunków w sieci

Jednym z głównych powodów zastosowania protokołu dynamicznego jest fakt, iż warunki w sieci zmieniają się od czasu do czasu. Ruter może się zawiesić lub uszkodzić, kable sieciowe może ktoś przeciąć, a łącza komunikacyjne mogą się zerwać. Wobec tego, każdy użyty protokół musi uporać się z takimi zmianami.

RIP rozgłasza swoje tablice tras co 30 sekund, co pozwala na propagację nowych tras i usuwanie starych. W pewnych warunkach RIP może mieć jednak problemy z metrykami odliczanymi do nieskończoności.

Odliczanie do nieskończoności

Gdy trasa do sieci w RIP przestaje być dostępna, ruter położony najbliżej punktu uszkodzenia przestaje otrzymywać aktualizacje od rutera sąsiedniego. Po upływie 180 sekund bez aktualizacji trasa zostaje uznana za nieosiągalną i jej metryka otrzymuje wartość 16 (jak pamiętamy, najwyższa dopuszczalna metryka wynosi 15, więc oznacza to brak dostępu do sieci). Gdy rutery udostępniają tablicę tras sąsiadom, metryki przyrastają.

Niektórzy z Czytelników mogą zauważyć w tym problem. Na przykład, na rysunku 19.13 jedna z sieci jest nieczynna. Ruter C posiada do sieci 10.10.4.0 trasę o metryce 2 przez ruter D; ruter B posiada do sieci 10.10.4.0 trasę o metryce 3 przez ruter C. Metryka trasy do sieci 10.10.4.0 zostanie ustawiona na 16, jeśli ruter C nie odbierze nic od rutera D przez okres trzech rozgłoszeń.

Jeśli ruter C jako pierwszy ogłosi swoją trasę, problemu nie będzie. „Widzi” on trasę do 10.10.4.0 z metryką 3, która jest lepsza od 16, więc ją zaakceptuje. Teraz ruter C rozgłosi swoje informacje o trasach, łącznie z trasą do 10.10.4.0 o metryce 4. Ruter B ustali, że jego trasa do 10.10.4.0 przechodzi przez ruter C i zaktualizuje swoją tablicę, więc metryka będzie wynosić 5. Proces ten będzie trwał przez jakiś czas, dopóki metryka w obu ruterach nie osiągnie 15. Zjawisko to nazywane jest problemem odliczania do nieskończoności i wyjaśnia, dlaczego najwyższa metryka wynosi 15.

Metody podziału horyzontu i zatrucia zwrotu

Odliczanie do nieskończoności oczywiście marnuje czas i przepustowość sieci. Można jednak zastosować dwie metody, które pomogą zmniejszyć ten problem. W pierwszej aktualizacje tras nie są wysyłane do sąsiada, od którego informacje o danych trasach zostały otrzymane. Gdyby w poprzednim przykładzie ruter B nie odesłał trasy z powrotem do rutera C, problem nie wystąpiłby. Ta metoda nosi nazwę podziału horyzontu (split horizons).

Rysunek 19.13. Odliczanie do nieskończoności

Druga metoda, nazywana zatruciem zwrotu (poisoned reverse), jest bardzo podobna do pierwszej, lecz inaczej traktuje aktualizacje. Odsyła je z powrotem do systemu, od którego poznała trasy, lecz z metryką 16. Jak widać, obie metody pozwalają uniknąć zapętlenia pomiędzy dwoma systemami; spójrzmy jednak na rysunek 19.14, w którym pojawił się dodatkowy ruter w sieci.

Rysunek 19.14. Bardziej złożony problem odliczania

Aktualizacje wyzwalane

W tej sieci w przypadku analogicznej awarii, ruter C wysyła aktualizację odebraną przez ruter A, lecz nie przez ruter B, z powodu zatoru lub podobnego problemu. Ruter A musi teraz oznaczyć trasę do 10.10.4.0 metryką 16. Ruter B wysyła aktualizacje i ruter A ustala, iż B posiada trasę do 10.10.4.0 z metryką 3. Ruter A wysyła swoje aktualizacje. Ponieważ uzyskał informacje o 10.10.4.0 od rutera B, przekazuje tę trasę ruterowi C.

Na tym etapie ruter A posiada trasę przez ruter B, który posiada trasę przez C, który z kolei posiada trasę przez A. Ponownie kończymy w pętli, zwiększając metryki aż do osiągnięcia 15. Żadna z dwóch poprzednich metod nie zapobiegnie problemowi odliczania do nieskończoności.

Aby zatrzymać tę pętlę, musimy dodać kolejną funkcję do protokołu RIP — aktualizacje wyzwalane (triggered updates). Funkcja ta pozwala ruterowi natychmiast wysłać aktualizację do innych w przypadku zmiany warunków.

Uprzątanie pamięci

Po całej tej dyskusji o przyrastaniu metryki do 16 Czytelnik przypuszczalnie zastanawia się, kiedy te trasy zostaną usunięte. Proces uprzątania pamięci (garbage collection) jest w rzeczywistości bardzo prosty. Po 180 sekundach bez aktualizacji trasa otrzymuje metrykę 16 i licznik czasu uprzątania pamięci zostaje ustawiony na 120 sekund; po odliczeniu do 0 trasa zostaje usunięta.

Wersja 2.

Wprawdzie protokół RIP w wersji pierwszej był zdatny do użytku, lecz sprawiał pewne problemy — na przykład, nie wysyłał razem z trasą maski sieci. RIP w wersji 2. (zdefiniowany w RFC 2453) to aktualizacja wersji 1., zawierająca zmiany w następujących dziedzinach:

• uwierzytelnianie,

• znaczniki tras,

• maski podsieci,

• adresy ruterów dla następnego hopu,

• obsługa adresowania grupowego.

Uwierzytelnianie

W wersji 1. nie istnieje żadna forma uwierzytelniania, co oznacza, że każdy ruter w sieci jest w stanie odczytać trasy i poznać strukturę sieci. Doprowadziło to do powstania „cichych” RIP — stacji, które jedynie nasłuchują rozgłoszeń RIP. W wersji 2. pierwszy wpis RIP może być oznaczony typem adresu 0xFFFF, co oznacza, że wpis ten jest informacją uwierzytelniającą. Wybór takiego sposobu uwierzytelnienia pozwala na użycie więcej niż jednego typu uwierzytelniania.

Jedyną obecnie zaimplementowaną metodą jest uwierzytelnianie otwartym tekstem. Hasło może mieć do 16 znaków i jest przesyłane w postaci nie zaszyfrowanej. Nie wprowadza to jakiegoś wyjątkowego poziomu bezpieczeństwa, lecz stanowi krok we właściwym kierunku.

Znaczniki tras

Znacznik trasy (route tag) jest nowym atrybutem, który został dodany do drugiej wersji RIP i może zostać ustawiony dla dowolnej trasy w pakiecie RIP. Jego zadaniem jest umożliwienie systemom oznaczenia tras, poznanych przez inne protokoły. Na przykład, system używający OSPF może „dowiedzieć” się o trasie do innej sieci, którą musi ogłosić wewnętrznie w systemie autonomicznym. Od ruterów stosujących oba protokoły oczekuje się oznaczania tras w RIP, aby nie były traktowane jak zwykłe trasy RIP.

Maski podsieci

Dodanie do pakietów RIP maski podsieci pozwala pracować z różnymi typami schematów podziału na podsieci, łącznie z VLSM i nadsieciami. Pewne problemy mogą nadal pozostać — na przykład, jeśli pomieszamy rutery używające RIP w wersjach 1. i 2.

Na przykład, dla VLSM RIP w wersji 1. nie rozpoznaje różnicy pomiędzy 10.10.10.0/23 a 10.10.10.0/27, wobec tego potraktuje obie jako trasy do tej samej sieci. Jeśli planujemy wykorzystanie VLSM, RIP w wersji 1. nie powinien być używany.

Ten sam scenariusz występuje w przypadku bezklasowego trasowania domen internetowych (CIDR). W tej technologii możemy na przykład połączyć dwie sieci klasy C — 192.14.2.0 i 192.14.3.0 — w jedną podsieć klasy B 192.14.2.0 z maską 255.255.254.0. Ponieważ RIP w wersji 1. nie wysyła maski podsieci, ten scenariusz również nie zadziała.

Adres rutera dla następnego hopu

Wpisy w pakietach RIP wersji 2. powinny zawierać pole następnego hopu, czyli kolejnego rutera, do którego pakiet będzie przesłany. Ten adres ma za zadanie zmniejszyć liczbę nieistotnych hopów w sieciach, w których nie wszystkie rutery obsługują RIP. Dla trasy do sieci, z którą ruter jest bezpośrednio połączony, pole zawiera 0.0.0.0.

Adresowanie grupowe

Zostało dodane adresowanie grupowe (multicasting), by zmniejszyć obciążenie systemów w sieci. Redukuje ono obciążenie innych systemów, ponieważ adres 224.0.0.9 będzie interesujący jedynie dla systemów, które nasłuchują tej transmisji. Pozostałe systemy odrzucą pakiet już w warstwie fizycznej, a nie w warstwie internetowej.

RIP jest protokołem prostym i skutecznym. Ograniczają go jedynie rozmiary sieci, jaką jest w stanie obsłużyć. Ograniczenie to czyni z protokołu RIP dobry wybór dla małych sieci. W sieciach dużych powinny być używane inne protokoły, na przykład Internet Gateway Routing Protocol (IGRP).

Protokół IGRP

Internet Gateway Routing Protocol (IGRP), opracowany przez Cisco w roli zastępcy protokołu RIP, jest również protokołem opartym na wektorach. Jest jednak znacznie lepszy, ponieważ:

Zapewnia stabilne trasowanie, nawet w dużych lub złożonych sieciach.

• Unika zapętlania tras, spotykanego w protokole RIP.

• Szybko reaguje na zmiany w topologii sieci.

• Mniej obciąża zasoby obliczeniowe niż RIP.

• Może równoważyć obciążenie pomiędzy trasami o mniej więcej podobnej przydatności.

• Może reagować na warunki na łączu i poziomy ruchu sieciowego.

• Może reagować na różne typy usług.

Jedną z zalet IGRP, w porównaniu z RIP, jest zdolność do rozpoznawania różnych typów ruchu sieciowego i tego, że wymagają one różnych typów sieci. Na przykład, jeśli przenosimy 300 - 400 MB plików z jednej lokalizacji do innej, pożądana jest jak największa jednostka transmisji (największe pakiety, jakie można przesłać daną trasą), lecz dopuszczalne są niewielkie opóźnienia. Natomiast wideokonferencje wymagają znacznie mniejszych objętości danych, lecz wszelkie opóźnienia w transmisji będą zauważalne.

Aby przystosować się do tych potrzeb, IGRP tworzy metrykę reprezentującą różne wartości, w tym:

• czas opóźnienia topologii,

• przepustowość najwolniejszego segmentu trasy,

• dostępność kanałów w trasie,

• niezawodność trasy.

Czas opóźnienia topologii oznacza czas, jaki zajmuje pakietowi dotarcie do miejsca przeznaczenia w nie obciążonej sieci. Parametr ten pozwala na wzięcie pod uwagę w liczonej metryce takich łączy, jak satelitarne, które mogą przesyłać duże objętości danych, lecz powodują opóźnienia, gdy dane przesyłane są pomiędzy naziemnymi stacjami przez satelitę. Na fakt, iż wartość opiera się na topologii nie obciążonej, brana jest poprawka wartości dostępności kanału, będącej zasadniczo bieżącym wykorzystaniem pasma w procentach. Przepustowość musi uwzględniać trasy, które obejmują wolniejsze łącza, na przykład linie 56 kb/s. Niezawodność również jest ważna, więc brana jest pod uwagę liczba retransmisji. Dostępność kanału i niezawodność są mierzone podczas komunikacji pomiędzy ruterami.

Cztery wymienione wcześniej wartości służą do utworzenia pojedynczej metryki, która reprezentuje jakość trasy. Pojedyncza metryka decyduje o tym, jakie informacje zachować w ruterze i służy do ustalenia, jak wysyłać dane z rutera. Poza tą metryką pomiędzy ruterami przesyłane są dodatkowo liczba hopów (liczba bram w trasie) oraz MTU (maximum transmission unit — maksymalna jednostka transmisji), aby rutery te mogły dokonywać optymalnych wyborów tras.

Podobnie jak w przypadku RIP, każdy ruter używający protokołu IGRP rozgłasza okresowo (domyślnie co 90 sekund) całą swoją tablicę tras do sąsiadujących ruterów. Tutaj również używana jest metoda podziału horyzontu, omówiona wcześniej przy okazji RIP, aby zapobiegać zapętlaniu tras. Rutery, które odebrały rozgłoszenie, sprawdzają trasy i dodają do swoich tablic tras wszelkie nowe (lub lepsze) trasy.

Rutery używają tych informacji, aby ustalić najlepszą trasę dla wszelkich danych, jakie muszą przesłać. Kalkulacja opiera się na wartościach z tablicy tras i dwóch wartościach wagowych. Pierwszą jest waga przepustowości (WP), która służy do ustalenia ważności dostępnego pasma. Druga to waga opóźnień (WO), która ustala ważność opóźnień. Wzór, na podstawie którego wyliczana jest najlepsza trasa, wygląda następująco:

((WP/(MP*(1-ZK)))+(WO*OT))*NT

W tym wzorze MP oznacza minimalną przepustowość, ZK dostępność kanału, OT opóźnienie topologii i NT niezawodność trasy.

Trasa, dla której wyliczona wartość będzie najniższa, zostanie wybrana. Jeśli do sieci docelowej istnieje więcej tras i dla dwóch lub więcej wartość będzie równa i najniższa, ruter wykorzysta obie, dzieląc dane pomiędzy nie. Za pomocą tego wzoru ruter może teraz dostosować się do różnych typów usług, dobierając różne wartości wagowe. Dodatkowo można uzyskać równoważenie obciążenia przez zapisywanie pełnych tras.

Dzięki wymienionym udoskonaleniom IGRP jest protokołem lepszym od RIP. Jednakże IGRP jest również wewnętrznym protokołem bramowym, czyli jest przeznaczony do użytku w pojedynczym systemie autonomicznym. W następnej kolejności przyjrzymy się zewnętrznemu protokołowi bramowemu OSPF.

OSPF

Na skutek ciągłego rozwoju sieć osiąga w pewnym momencie skalę, przy której nie można jej traktować jako pojedynczego systemu autonomicznego. Protokół OSPF (Open Shortest Path First — najpierw najkrótsza otwarta trasa) został zaprojektowany, by rozwiązać ten dylemat dzieląc sieć na obszary trasowania. OSPF używa lepszych metryk niż RIP w wersji 2. (zdefiniowanych w RFC 2238) i dodatkowo utrzymuje informacje o stanie wszystkich interfejsów we wszystkich ruterach. Dzięki temu każdy ruter OSPF może ustalić ze swojej perspektywy optymalną trasę dla danych. Protokół OSPF ma między innymi następujące właściwości:

• brak ograniczeń dotyczących liczby hopów,

• obsługa VLSM,

• użycie adresowania grupowego do aktualizacji stanów łączy,

• szybsza zbieżność, ponieważ aktualizacje stanów łączy są wysyłane natychmiast,

• metryki obejmują informacje o opóźnieniach łączy, nie tylko o liczbie hopów,

• obsługa równoważenia obciążenia,

• podział sieci na obszary, które mogą zawierać do ok. 50 ruterów,

• uwierzytelnianie otwartym tekstem lub za pomocą algorytmu mieszania
  message-digest,

• znaczniki tras zewnętrznych.

Jak Czytelnik zapewne się domyślił, z funkcjami tymi są związane pewne koszty — po pierwsze, ruch w sieci pochodzący od stosowanego OSPF (ponieważ każde łącze w każdym ruterze musi być monitorowane przez wszystkie rutery w danym obszarze, obsługa infrastruktury trasowania może wymagać dodatkowych transmisji). Po drugie — nakłady pracy na planowanie, które jest wymagane przy konfiguracji wdrożenia OSPF. Na koniec, ponieważ rutery obliczają dla siebie „najlepsze trasy”, same rutery muszą posiadać więcej zasobów — szybsze procesory i więcej pamięci.

Stany i koszty łączy

Każdy ruter zajmuje się zarządzaniem i propagacją informacji o stanie łączy, co oznacza, że dla każdego połączenia logicznego gromadzi kilka informacji (adres IP, maska podsieci, topologia używana w łączu, inne dostępne rutery używające tego łącza itp.). Informacje te są propagowane do wszystkich ruterów w obszarze za każdym razem, gdy stan łącza ulega zmianie.

Gdy ruter jest inicjowany lub stan jednego z jego łączy ulega zmianie, wówczas tworzy ogłoszenie stanów łączy, które zostanie wysłane do wszystkich sąsiednich ruterów, na przykład RIP lub IGRP. Sąsiadujące rutery zapisują kopię tych informacji i przekazują ogłoszenie do wszystkich innych znanych sobie sieci — proces ten nosi nazwę trasowania rozpływowego (flooding). Po zaktualizowaniu bazy danych każdy ruter przelicza ponownie swoje drzewo najkrótszych tras, które stanowi listę sieci docelowych, skojarzonych kosztów i następnych hopów.

Podczas obliczania drzewa najkrótszych tras musi zostać wzięty pod uwagę koszt każdego łącza. Ponieważ każdy ruter w rzeczywistości zna typ połączeń, jakie mają pozostałe rutery w obszarze, OSPF może obliczyć koszt całej trasy, nie tylko koszt oparty na wartości z sąsiedniego rutera. Koszt jest wyliczany wyłącznie na podstawie odwrotności przepustowości łącza. Za szybkie łącze uznaje się 100 Mb/s, więc dla połączenia 100 Mb/s koszt wynosi 1. Koszt połączenia 10 Mb/s wynosi 100/10 = 10, zaś koszt łącza T1 o przepustowości 1,544 Mb/s wynosi 100/1,544 = 64.

Podczas tworzenia drzewa najkrótszych tras ruter „zakłada”, iż jest centrum sieci i że znajdzie najkrótszą trasę do dowolnej sieci poprzez swojego sąsiada. Rozważmy sieć z rysunku 19.15.

Rysunek 19.15. Diagram przedstawiający drzewo najkrótszych tras dla rutera A

Na tym rysunku ruter buduje drzewo, aby znaleźć wszystkie możliwe trasy i przydzielić wartości kosztów do wszystkich łączy w trasie. Koszt dla sieci lokalnych wynosi 0, zaś dla pozostałych — jest wyliczany na podstawie przepustowości, jak omówiliśmy to przed chwilą. Ten proces doprowadzi do utworzenia drzewa, które będzie wyglądało jak na rysunku 19.15.

Korzystając z drzewa najkrótszych tras, ruter zbuduje teraz swoją tablicę tras. W naszym przykładzie będą dwie trasy do 10.10.3.0 i 10.10.4.0, co pozwoli ruterowi równoważyć obciążenie pomiędzy dwie nadmiarowe trasy.

W stabilnej sieci OSPF sprawuje się dobrze i nie używa nadmiernych ilości pasma. Jednakże w sieci niestabilnej OSPF może sprawić problemy z wydajnością, z powodu zalewów (trasowania rozpływowego) i stałego odtwarzania drzew najkrótszych tras i tablic tras.

Łączenie obszarów w sieć

Jak już wspomniano, OSPF pozwala na podział systemu autonomicznego na obszary, co oznacza możliwość rozbudowy sieci do olbrzymich rozmiarów. W zależności od topologii i stabilności, „realistyczna” liczba ruterów w dowolnym obszarze wynosi około 50. Powyżej tej liczby „wrodzona” niestabilność sieci i liczba ruterów, które trzeba aktualizować, zaczynają poważnie wpływać na wydajność.

Wprawdzie 50 ruterów może wydawać się dużą liczbą, lecz wiele sieci znacznie ją przekracza. W ich przypadku trzeba podzielić sieć na osobne obszary. Podziału możemy dokonać też z innych powodów, na przykład z uwagi na odrębnie administrowane obszary.

W gruncie rzeczy obszar ogranicza zasięg zalewów (flooding). Aktualizacje stanu łączy są wysyłane tylko do ruterów w tym samym obszarze, co uniemożliwia znalezienie pełnej trasy do hosta w innym obszarze. Zamiast tego rutery obliczają najlepsze trasy do ruterów brzegowych obszaru. Te rutery służą nie tylko do przesyłania danych pomiędzy obszarami, lecz również do wymiany informacji o trasach w obszarach, z którymi się łączą. Rutery wewnątrz obszaru można nazwać ruterami wewnętrznymi, aby odróżnić je od ruterów brzegowych.

Jeden obszar w sieci OSPF jest wyznaczony do roli szkieletu (Obszar 0), z którym powinny łączyć się wszystkie rutery brzegowe obszarów. Ten wspólny obszar pozwala ruterom brzegowym utworzyć sumę informacji o łączach w obsługiwanych przez nie obszarach; te informacje mogą zostać udostępnione innym ruterom brzegowym obszarów poprzez Obszar 0. Rysunek 19.16 przedstawia, jak może wyglądać Obszar 0.

W niektórych przypadkach podłączenie wszystkich ruterów brzegowych obszarów do Obszaru 0 jest niemożliwe — na przykład, jeśli sieć jest geograficznie rozproszona na wiele różnych regionów, z niewielką liczbą szybkich połączeń pomiędzy grupami lokalizacji. W takich przypadkach tworzone są łącza wirtualne.

Gdy połączenie fizyczne nie jest możliwe, łącza wirtualne mogą posłużyć do połączenia ze sobą odległych fragmentów Obszaru 0. Łącze wirtualne może przebiegać przez inny obszar, połączony z wszystkimi fragmentami Obszaru 0 — posiadający w części wspólnej z każdym z tych fragmentów ruter brzegowy. Łącze wirtualne jest wówczas tworzone pomiędzy tymi ruterami brzegowymi obszaru.

Rysunek 19.16. Sieć OSPF może zostać podzielona na obszary, aby zmniejszyć obciążenie sieci przez trasowanie rozpływowe, oraz aby zmniejszyć obciążenie ruterów spowodowane przeliczaniem tablic tras

Ten sam proces może posłużyć do połączenia odległego obszaru z Obszarem 0. W tym celu pomiędzy obszarem odległym i drugim, połączonym z Obszarem 0, zostaje umieszczony ruter brzegowy, który może być wykorzystany do utworzenia wirtualnego łącza z ruterem brzegowym, który jest podłączony bezpośrednio do Obszaru 0.

Inne funkcje ruterów

Czytelnik powinien rozumieć już różnicę pomiędzy ruterami wewnętrznymi i brzegowymi obszaru. Jednakże ruter może grać jeszcze inne role, które nie zostały tu omówione. Na przykład, może grać rolę rutera brzegowego systemu autonomicznego (ASBR — Autonomous System Border Router). ASBR służą do łączenia systemu autonomicznego z innymi systemami autonomicznymi, które używają innych protokołów.

Trasy, które pozna ASBR, są rozprowadzane w sieci. Trasy są streszczane przez ASBR, ponieważ rutery te mogą być podłączone do bardzo dużych sieci. Proces umieszczania tych zewnętrznych łączy w sieci OSPF nosi nazwę redystrybucji. Informacje są gromadzone z innych protokołów, na przykład RIP lub IGRP, a następnie redystrybuowane w sieci OSPF.

Rutery muszą również znajdować inne rutery, z którymi dzielą połączenia. Inaczej mówiąc, ruter powinien „wiedzieć” o wszystkich pozostałych ruterach we wspólnych segmentach fizycznych. W OSPF proces znajdowania innych ruterów nosi nazwę procesu znajdowania sąsiadów (neighbour process). Proces ten wykorzystuje pakiety Hello, które są prostymi pakietami, zawierającymi listę znanych sąsiadów i inne informacje o ruterze wysyłającym pakiet. Pakiety Hello są wysyłane okresowo do adresów grupowych. Po odebraniu pakietu Hello dodawane są wszelkie systemy nie znajdujące się na liście sąsiadów. Aby dwa rutery mogły zostać sąsiadami, muszą znajdować się w jednym obszarze (aby mogły uwierzytelniać się u siebie nawzajem). Ponadto rutery te uzgadniają interwały Hello (interwał przywitania) i Dead (czas zwłoki). Interwał przywitania oznacza częstotliwość, z jaką ruter wysyła pakiety Hello. Czas zwłoki oznacza czas, przez który ruter zachowuje sąsiada na liście, jeśli nie otrzymuje od niego wiadomości.

Rutery stosują proces znajdowania sąsiadów do wzajemnej identyfikacji, a następnie wybierają „rzecznika”, inaczej ruter desygnowany (DR — Designated Router) dla danej grupy sąsiadów. DR koordynuje aktualizacje informacji w całym obszarze. Inaczej mówiąc, każdy ruter przesyła aktualizacje do DR, który następnie rozsyła je do wszystkich pozostałych ruterów. DR jest ruterem o najwyższym priorytecie OSPF. Istnieje jeszcze zapasowy ruter desygnowany dla danej grupy sąsiadów, który jest używany w razie awarii DR.

Po wyborze DR wszystkie pozostałe rutery z danego obszaru usiłują uformować przyległość z tym ruterem. Ten proces idzie dalej niż zwykłe pakiety Hello i pozwala ruterom wymieniać między sobą bazy danych. Gdy proces ten zostaje uruchomiony, przyległość jest oznaczona jako nieczynna. W trakcie procesu znajdowania sąsiadów przyległość jest oznaczona jako Init — co oznacza, że pakiety Hello zostały zauważone — a następnie jako Two-Way (dwukierunkowa), gdy sąsiedzi zostaną znalezieni. Przyległość naprawdę zaczyna się w procesie znajdowania sąsiadów. Rutery przechodzą następnie w stan wymiany (Exchange), w którym wysyłają do siebie nawzajem bazy danych. Dwa rutery pobierające od siebie informacje wchodzą w stan Loading (ładowania). Na koniec przyległość zostaje oznaczona jako pełna (Full) i każda para baz danych zawiera wszystkie informacje o obu ruterach.

Oczywiście proces znajdowania sąsiadów i budowania przyległości wymagają stosowania mediów, które przenoszą rozgłoszenia. Niektóre nośniki, na przykład frame relay i ATM, nie używają rozgłoszeń, co oznacza, że w każdym ruterze trzeba skonfigurować adresy IP sąsiadów. Konfiguracja dwupunktowego podinterfejsu lub interfejsu punkt-grupa również nadaje się do tego, ponieważ podają one ruterom adresy sąsiadów. Przez skonfigurowanie dwupunktowego podinterfejsu pomiędzy każdym ruterem i DR oraz zapasowym ruterem desygnowanym, możemy zapewnić aktualizowanie wszystkich baz danych. Wykorzystanie interfejsu punkt-grupa zmniejsza liczbę podinterfejsów, które trzeba skonfigurować.

386 Część IV Tworzenie i utrzymanie sieci TCP/IP

Rozdział 19. Projektowanie trasowania dla sieci 385

---