Protokoły routingu dynamicznego

Autor:

Waldemar Pierścionek

W artykule tym kontynuujemy omawianie zagadnień związanych z procesem routingu.

Przedstawimy między innymi poszczególne typy protokołów routingu dynamicznego,
charakterystykę protokołów RIP oraz IGRP, metody zapobiegania powstawaniu pętli

między routerami oraz konfigurowanie redystrybucji danych o routingu.

W dużych sieciach wielosegmentowych routing dynamiczny jest podstawową metodą zdobywania wiedzy, dzięki
której routery poznają topologię sieci oraz budują tabele routingu. Wymiana informacji między routerami odbywa się

zgodnie z określonymi algorytmami i przy wykorzystaniu protokołów routingu dynamicznego. Według typowej
klasyfikacji, protokoły routingu dynamicznego dzielą się na protokoły wektora odległości (distance vector) oraz

protokoły stanu łącza (link state). Inny podział wyodrębnia grupy protokołów klasowych i bezklasowych.

Protokoły wektora odległości

Protokół wektora odległości - informacje o poszczególnych sieciach "propagują" się stopniowo. Na przykład router A dopiero po

dwóch cyklach czasowych uzyska informacje o sieci 11.1.4.0.

Routery używające protokołów wektora odległości regularnie wysyłają kompletną zawartość swojej tabeli routingu

do wszystkich routerów sąsiednich, a te z kolei przesyłają informacje dalej (p. rysunek str. 67). Warto zwrócić
uwagę na to, że router ogłasza nie tylko sieci, do których jest bezpośrednio podłączony, ale także te, których

nauczył się od sąsiadów - protokoły tej grupy określa się też mianem "routing poprzez plotkowanie". Jako sposób
wymiany danych stosowana jest najczęściej komunikacja rozgłoszeniowa (broadcast), chociaż niektóre protokoły

wykorzystują multiemisję (multicast).

Nazwa "wektor odległości" pochodzi stąd, iż poszczególne trasy ogłaszane są jako wektory zawierające dwie
informacje: odległość oraz kierunek. Odległość opisuje koszt danej trasy i wyrażana jest za pomocą metryki,

natomiast kierunek definiowany jest poprzez adres następnego skoku. Protokoły wektora odległości są łatwe w
konfiguracji i bardzo dobrze nadają się do zastosowania w małych sieciach. Niestety, jednym z ich podstawowych

problemów jest tzw. zbieżność, czyli powolne reagowanie na zmiany zachodzące w topologii sieci, na przykład
wyłączenie lub włączenie pewnych segmentów - zerwanie łącza zostaje odzwierciedlone w tabelach routingu
poszczególnych routerów dopiero po pewnym czasie. Czas, po którym wszystkie routery mają spójne i uaktualnione

tabele routingu nazywany jest czasem zbieżności. Kolejną wadą protokołów wektora odległości jest generowanie
dodatkowego ruchu w sieci poprzez cykliczne rozgłaszanie pełnych tabel routingu, nawet wówczas, gdy w topologii

sieci nie zachodzą żadne zmiany. Protokoły tej grupy nie są też odporne na powstawanie pętli między routerami
(zarówno między bezpośrednimi sąsiadami, jak i pętli rozległych), co skutkuje wzajemnym odsyłaniem sobie

pakietów z informacją o tej samej sieci. Mechanizmy pozwalające unikać powstawania takich pętli omówimy w

dalszej części artykułu.

Należy zwrócić również uwagę na problem propagacji błędnych informacji. Przykładowy Router A, otrzymujący dane

od swojego sąsiada B, musi zakładać, iż są one poprawne, gdyż nie ma żadnego sposobu na ich zweryfikowanie i
ewentualne wykrycie błędów w tabeli routingu routera B. To oczywiście oznacza, że router A również będzie

przekazywał błędne informacje do swoich pozostałych sąsiadów.

Ważnym parametrem dla protokołów wektora odległości jest maksymalna rozpiętość sieci, czyli maksymalna

dopuszczalna w danym protokole liczba kolejnych routerów (skoków) na ścieżce wiodącej do sieci docelowej. Sieci
dostępne przez większą od dozwolonej liczbę skoków oznaczane są jako nieosiągalne. Protokoły wektora odległości
pracują zgodnie z algorytmami opracowanymi przez R.E.Bellmana, L.R.Forda i D.R.Fulkersona, a typowymi

przedstawicielami tej grupy są RIP oraz IGRP.

Protokoły stanu łącza

Protokół stanu łącza

W protokołach stanu łącza każdy router przechowuje kompletną bazę danych o topologii sieci z informacjami o
koszcie pojedynczych ścieżek w obrębie sieci oraz o stanie połączeń. Informacje te kompletowane są poprzez
rozsyłanie tzw. pakietów LSA (link-state advertisement) o stanie łączy. Każdy router wysyła informację o

bezpośrednio do niego podłączonych sieciach oraz o ich stanie (włączone lub wyłączone). Dane te są następnie
rozsyłane od routera do routera, każdy router pośredni zapisuje u siebie kopię pakietów LSA, ale nigdy ich nie

zmienia. Po pewnym czasie (czasie zbieżności) każdy router ma identyczną bazę danych o topologii (czyli mapę
sieci) i na jej podstawie tworzy drzewo najkrótszych ścieżek SPF (shortest path first) do poszczególnych sieci.

Router zawsze umieszcza siebie w centrum (korzeniu) tego drzewa, a ścieżka wybierana jest na podstawie kosztu
dotarcia do docelowej sieci - najkrótsza trasa nie musi pokrywać się z trasą o najmniejszej liczbie skoków. Do

wyznaczenia drzewa najkrótszych ścieżek stosowany jest algorytm E.W. Dijkstry. Ponieważ każdy router ma
identyczną bazę danych informacji o sieci, protokoły stanu łącza są znacznie bardziej odporne na rozgłaszanie

przypadkowych błędów ogłaszane przez sąsiadów niż protokoły wektora odległości. Ponadto drzewo rozpinające sieć

pozbawione jest w naturalny sposób rozległych pętli łączących routery.

Jedną z najważniejszych cech protokołów stanu łącza jest szybkie reagowanie na zmiany w topologii sieci. Po

zmianie stanu łącza router generuje nowy pakiet LSA, który rozsyłany jest od routera do routera, a każdy router
otrzymujący ten pakiet musi przeliczyć od nowa drzewo najkrótszych ścieżek i na jego podstawie zaktualizować

tabelę routingu.

Protokoły stanu łącza nazywane są też protokołami "cichymi", ponieważ w przeciwieństwie do protokołów wektora
odległości nie rozsyłają cyklicznych ogłoszeń, a dodatkowy ruch generują tylko przy zmianie stanu łącza. Ze względu

na sposób działania i swoje cechy protokoły stanu łącza przeznaczone są do obsługi znacznie większych sieci niż

protokoły wektora odległości.

Do wad protokołów stanu łącza zaliczyć można zwiększone zapotrzebowanie na pasmo transmisji w początkowej

fazie ich działania (zanim "ucichną"), gdy routery rozsyłają między sobą pakiety LSA. Dodatkowo ze względu na
złożoność obliczeń drzewa SPF, protokoły stanu łącza mają zwiększone wymagania dotyczące procesora i pamięci

RAM routera (zwłaszcza przy większych sieciach). Typowym przedstawicielem tej grupy protokołów jest OSPF (Open

Shortest Path First).

Protokoły klasowe

Jako sieć główną przyjmuje się adres sieci zgodny z klasą adresu IP.

Podstawową cechą protokołów klasowych jest to, iż nie ogłaszają one maski podsieci razem z adresem sieci. Router

odbierający może zastosować maskę z własnego interfejsu, jeśli interfejs ma adres IP z tej samej sieci głównej, co
sieć ogłaszana.

Przykładowy układ dwóch routerów pracujących z protokołem klasowym. Wszystkie interfejsy zostały skonfigurowane z adresami

IP z tej samej sieci głównej klasy B 170.71.0.0. Jednak interfejs szeregowy routera B (połączenie z routerem A) ma przypisaną

dłuższą maskę podsieci niż pozostałe interfejsy (255.255.255.252).

Sposób ogłaszania tras do routerów sąsiednich prześledzimy na przykładzie układu przedstawionego na rysunku

obok. Dla protokołów klasowych stosowane są następujące zasady ogłaszania sieci lub podsieci:

•

Jeżeli podsieć oraz interfejs, przez który jest ogłaszana, mają identyczną sieć główną oraz jednakowej
długości maskę podsieci, to podsieć będzie ogłaszana poprawnie (poprawny adres sieci, ale bez maski). Na

przykład router A ogłasza przez interfejs S0 (p. rysunek) podsieć 170.71.5.0 (sieć LAN), a router B

interpretuje to ogłoszenie z maską podsieci własnego interfejsu S0 (w tym wypadku maska ma 30 bitów).

•

Jeżeli podsieć ma taką samą sieć główną jak interfejs, przez który ma być ogłoszona, ale inną maskę
podsieci, podsieć ta nie będzie w ogóle ogłaszana. Na przykład router B na rysunku nie będzie ogłaszał

przez interfejs S0 podsieci 170.71.8.0, ponieważ jej maska (24 bity) jest niezgodna z maską interfejsu S0

(30 bitów).

•

Jeżeli ogłaszana podsieć ma inną sieć główną niż interfejs, przez który jest ogłaszana, router wysyłający
ogłoszenie dokonuje automatycznego przekształcenia na adres sieci głównej, czyli adres wynikający z

klasy. Proces ten nazywany jest łączeniem tras na granicy sieci głównych (p. rysunek).

Łączenie tras na granicy sieci głównych

Jednym z problemów wynikających ze stosowania protokołów klasowych jest brak obsługi tzw. sieci nieciągłych.
Sieci nieciągłe to dwie podsieci tej samej sieci głównej rozdzielone inną siecią główną - p. rysunek poniżej.

Interfejsy Ethernet routerów A i B mają przypisane adresy IP z różnych podsieci sieci głównej 170.71.0.0. Na
interfejsach szeregowych łączących routery wykorzystywana jest sieć główna 170.73.0.0. W tej sytuacji router A,

ogłaszając sieć 170.71.5.0 do swojego sąsiada, będzie musiał dokonać przekształcenia na adres wynikający z klasy
(granica sieci głównych). Ogłoszenie sumaryczne dociera do routera B, ale jest ignorowane, ponieważ router B ma

dokładniejsze informacje o sieci 170.71.0.0, gdyż jest lokalnie podłączony do podsieci 170.71.8.0.

Analogicznie wygląda przypadek ogłaszania podsieci 170.71.8.0 do routera A. W efekcie ani router A, ani B nie będą
miały w tabelach routingu informacji o podsieciach IP stosowanych w segmentach LAN swojego sąsiada.

Rozwiązaniem tego problemu jest na przykład zastosowanie protokołu bezklasowego, który dzięki ogłaszaniu
również maski podsieci, pozwala na wyłączenie automatycznego łączenia tras na granicy sieci głównych (ogłaszana

jest poprawna długość podsieci), a router odbierający ogłoszenie może zapisać w tabeli routingu adres sieci IP o
poprawnej długości. W przypadku sieci nieciągłych można posłużyć się także drugorzędnymi adresami IP należącymi

do tej samej sieci głównej co nieciągłe podsieci. Adresy drugorzędne należy przypisać do wszystkich interfejsów na
trasie między podsieciami nieciągłymi - p. rysunek.

Kolejny adres przypisujemy do interfejsu poleceniem konfiguracyjnym interfejsu: ip address adres_IP

Maska_Podsieci secondary

Przykład sieci nieciągłej

Sieci 10.45.5.0 za routerem A oraz 10.45.35.0 za routerem C należą do tej samej sieci głównej 10.0.0.0 i są
przykładem podsieci nieciągłych rozdzielonych inną siecią główną: 192.168.11.0 oraz 192.168.80.0. Dzięki

przypisaniu adresów drugorzędnych należących do różnych podsieci tej samej sieci głównej 10.0.0.0, ogłaszanie
informacji przez poszczególne interfejsy na trasie między routerem A i C nie wymaga łączenia tras na granicy sieci

głównych. Ogłaszanie realizowane jest niezależnie dla poszczególnych adresów IP przypisanych do interfejsu. W
omawianym przypadku przypisanie dwu adresów IP do interfejsu oznacza dwukrotny proces ogłaszania, niezależnie

dla adresu głównego i drugorzędnego.

Protokół RIP

RIP jest jednym z najstarszych przedstawicieli grupy protokołów wektora odległości. Jest to standard otwarty, a
jego podstawowa wersja opublikowana jest w dokumencie RFC 1058 (obecnie dostępna jest również wersja druga).

W wersji pierwszej RIP jest klasycznym przykładem protokołu wektora odległości, jest także protokołem klasowym,
a więc nie jest w nim ogłaszana maska podsieci. Wszelkie omówione wcześniej cechy protokołów klasowych są w

protokole RIP obecne. Protokół RIP nie ma własnego protokołu warstwy transportowej. Ogłoszenia realizowane są z
wykorzystaniem portu 520 dla protokołu UDP. Informacje między routerami są wymieniane standardowo, metodą

rozgłoszeniową (na poziomie warstwy sieciowej stosowany jest adres docelowy 255.255.255.255).

Aby zapobiec sytuacji, gdy wszystkie routery w tym samym czasie rozpoczynają rozsyłanie danych, faktyczny czas

aktualizacji wybierany jest z przedziału od 25,5 do 30 sekund.

W protokole RIP jedynym elementem wykorzystywanym do obliczenia metryki jest liczba skoków przez kolejne
routery na trasie do sieci docelowej. Jeżeli do wybranej sieci prowadzą dwie (lub więcej) trasy z jednakową liczbą

skoków, obie będą pokazywane w tabeli routingu, w innych sytuacjach pokazywana jest tylko trasa z najlepszą

metryką. Pełna tabela routingu ogłaszana jest do routerów sąsiednich cyklicznie co około 30 sekund.

Protokół RIP włączany jest głównym poleceniem konfiguracyjnym router RIP. Dodatkowo należy skonfigurować

proces RIP podkomendą network. Polecenie network ma podwójne znaczenie: po pierwsze określa, które z
bezpośrednio podłączonych sieci będą ogłaszane do routerów sąsiednich, po drugie wskazuje interfejsy routera,

które będą pracować w danym protokole. Składnia polecenia network jest następująca: network
Klasowy_Adres_Sieci. Polecenie network wymaga podania adresu sieci wynikającego z klasy, nie można

stosować adresu podsieci ani konkretnego adresu interfejsu. Nie podaje się również maski podsieci. Wyobraźmy
sobie sytuację przedstawioną na rysunku obok. Wykonanie tylko polecenia network 212.1.1.0 podczas

konfiguracji protokołu RIP spowoduje, że żadna z sieci bezpośrednio podłączonych nie będzie rozgłaszana przez
żaden interfejs (nie zostało włączone ogłaszanie na interfejsach S0 i S1, a sieć 212.1.1.0 domyślnie w ogóle nie jest

rozgłaszana przez interfejs E0, o czym więcej w dalszej części artykułu). Z kolei wykonanie tylko polecenia network
131.107.0.0 spowoduje ogłaszanie podsieci 131.107.12.0 przez interfejs S1 i podsieci 131.107.11.0 przez interfejs

S0. Tym razem sieć 212.1.1.0 w ogóle nie może być ogłaszana, a dodatkowo podsieci sieci głównej 131.107.0.0 nie
będą ogłaszane przez interfejs E0 (nie jest objęty poleceniem network). Aby przykładowy router A ogłaszał

wszystkie sieci przez wszystkie interfejsy, wymagana będzie następująca konfiguracja:

RouterA(config)#router RIP

RouterA(config-router)#network 131.107.0.0

RouterA(config-router)#network 212.1.1.0

Przykładowy układ czterech routerów w pętli

W kilku kolejnych zagadnieniach dotyczących protokołu RIP będziemy wykorzystywać układ czterech routerów

połączonych w zamkniętej pętli (p. rysunek). Konfiguracja routera c2600 jest następująca:

c2600(config)#router RIP

c2600(config-router)#network 131.107.0.0

c2600(config-router)#network 131.108.0.0

Konfiguracja pozostałych routerów będzie analogiczna (każdy z nich ogłaszać będzie inną sieć IP stosowaną w

segmencie LAN). Aby wyświetlić zawartość tabeli routingu, na routerze c2600 wykonujemy polecenie show ip
route:

Gateway of last resort is not set

R 212.1.1.0/24 [120/1] via 131.107.12.2, 00:00:03, Serial0/0

R 10.0.0.0/8 [120/1] via 131.107.13.2, 00:00:10, Serial0/1

R 196.168.2.0/24 [120/2] via 131.107.13.2, 00:00:10, Serial0/1

[120/2] via 131.107.12.2, 00:00:04, Serial0/0

131.108.0.0/24 is subnetted, 1 subnets

C 131.108.1.0 is directly connected, Ethernet0/0

131.107.0.0/24 is subnetted, 4 subnets

R 131.107.10.0 [120/1] via 131.107.13.2, 00:00:10, Serial0/1

R 131.107.11.0 [120/1] via 131.107.12.2, 00:00:04, Serial0/0

C 131.107.12.0 is directly connected, Serial0/0

C 131.107.13.0 is directly connected, Serial0/1

Protokół RIP - parametry czasowe

Update (czas aktualizacji) - czas wysyłania kolejnych aktualizacji. W protokole RIP domyślnie około 30 sekund.
Invalid (trasa nieważna) - zegar uruchamiany razem z ostatnią aktualizacją. Przy braku aktualizacji, po przekroczeniu tego czasu

trasa oznaczana jest jako nieważna, ale nie jest automatycznie usuwana z tabeli routingu, tylko przechodzi w tryb przytrzymania
trasy (hold down). W protokole RIP czas ten wynosi domyślnie 180 sekund (6 czasów aktualizacji).

Hold down (przytrzymywanie trasy) - czas przetrzymywania w tabeli routingu tras nieważnych (nieaktualizowanych). Trasa w tym
trybie oznaczana jest w tabeli routingu jako "possibly down", ale jest cały czas wykorzystywana do wysyłania pakietów i router nie

akceptuje ewentualnych ogłoszeń tej trasy od innych sąsiadów. Zastosowano tutaj zasadę, że lepiej przytrzymać w tabeli routingu
trasę być może uszkodzoną, niż zbyt szybko przełączyć się na inną trasę do tej samej sieci, ale z wyższą metryką. W protokole RIP

czas ten wynosi domyślnie 180 sekund (chyba że wcześniej skończy się czas flush).
Flush (usuwanie trasy z tabeli) - czas, po którym trasa nieaktualizowana usuwana jest z tabeli routingu. Zegar ten uruchamiany

jest razem z ostatnią aktualizacją trasy. Ponieważ w protokole RIP czas ten wynosi domyślnie 240 sekund, więc w praktyce trasa

nieaktualizowana usunięta zostanie z tabeli routingu już po 60 sekundach trybu hold down (plus 180 sekund czasu invalid).

Sieci zgłaszane dynamicznie w protokole RIP oznaczane są literką R, wiarygodność protokołu RIP standardowo
ustawiona jest na wartość 120, a metryka to po prostu liczba skoków do sieci docelowej. Zwróćmy uwagę, że dla
każdej pozycji zgłaszanej dynamicznie wyświetlany jest też czas jej ostatniej aktualizacji (w normalnych warunkach

poniżej 30 sekund dla protokołu RIP). Sieć 196.168.2.0 z punktu widzenia routera c2600 dostępna jest przez dwie
jednakowo dobre (metryka) trasy, odpowiednio przez interfejs S0/0 i S0/1. W przypadku uruchomienia przełączania

procesowego - pakiet po pakiecie (omawialiśmy to w poprzednim artykule) - router realizowałby równoważenie

ruchu, przesyłając połowę pakietów przez pierwszy interfejs, a połowę przez drugi.

W przypadku wystąpienia trudnych do zidentyfikowania problemów z ogłaszaniem tras w protokole RIP, najlepiej
posłużyć się poleceniem debug. Przykładowo komenda debug ip RIP pozwala śledzić tylko ruch związany z
protokołem RIP, z dokładnym podziałem, jakie sieci są ogłaszane bądź otrzymywane przez poszczególne interfejsy.

W poniższym fragmencie komunikatów wyświetlanych w trybie śledzenia na routerze c2600 zauważmy podawaną

liczbę skoków bądź metrykę, stosowaną wersję protokołu RIP (v1) oraz podział na ogłaszane podsieci i sieci główne:

00:53:23: RIP: received v1 update from 131.107.13.2

on Serial0/1

00:53:23: 10.0.0.0 in 1 hops

00:53:23: 131.107.10.0 in 1 hops

00:53:23: 131.107.11.0 in 2 hops

00:53:23: 196.168.2.0 in 2 hops

00:53:29: RIP: sending v1 update to 255.255.255.255

via Serial0/0 (131.107.12.1)

00:53:29: subnet 131.107.10.0, metric 2

00:53:29: subnet 131.107.13.0, metric 1

00:53:29: network 10.0.0.0, metric 2

00:53:29: network 131.108.0.0, metric 1

Oprócz omawianego wcześniej czasu aktualizacji, w procesie zarządzania zawartością tabeli routingu uwzględniane

są jeszcze inne parametry czasowe - p. ramka.

Domyślne parametry czasowe stosowane w protokole RIP zmodyfikować można poleceniem: timers basic update

invalid holddown flush.

Aby zilustrować stosowanie poszczególnych czasów, posłużymy się przedstawionym wcześniej układem czterech
routerów i w tabeli routingu routera c2600 będziemy obserwować sieć 212.1.1.0 (LAN za routerem A), która nie

będzie poprawnie aktualizowana. W tym celu w konfiguracji protokołu RIP na routerze A należy wyłączyć wysyłanie

ogłoszeń przez interfejs Serial 0 poleceniem:

RouterA(config-router)#passive-interface Serial0

Przez pierwsze 180 sekund trasa pokazywana jest poprawnie i wykorzystywana jest podczas przesyłania pakietów

do sieci 212.1.1.0 (tylko czas ostatniej aktualizacji zwiększa się powyżej 30 sekund):

R 212.1.1.0/24 [120/1] via 131.107.12.2, 00:01:13, Serial0/0

Po upływie około 3 minut kończy się czas invalid i trasa przechodzi w tryb hold down, w którym nadal będzie
wykorzystywana do obsługi ruchu dla sieci 212.1.1.0:

R 212.1.1.0/24 is possibly down, routing via 131.107.12.2, Serial0/0

Teoretycznie trasa może pozostawać w trybie hold down przez 180 sekund, ale już po 60 sekundach kończy się czas
flush (zegar ten uruchamiany jest razem z ostatnią aktualizacją) i trasa usuwana jest z tabeli routingu, a na jej

miejsce pojawia się nowy wpis, prowadzący do sieci 212.1.1.0 przez router B z wyższą metryką równą 3:

R 212.1.1.0/24 [120/3] via 131.107.13.2, 00:00:10, Serial0/1

Po wyłączeniu komendy passive-interface, do tabeli routingu natychmiast powraca pierwotna trasa do sieci

212.1.1.0, ponieważ jest ogłaszana z lepszą metryką (1 skok).

Jedną z głównych wad protokołu RIP jest sposób obliczania metryki, uwzględniający tylko liczbę skoków do sieci
docelowej. Przy obliczaniu kosztu danej trasy w ogóle nie uwzględnia się parametrów transmisyjnych, takich jak

przepustowość, wprowadzane opóźnienie czy obciążenie poszczególnych interfejsów. Powróćmy do poprzedniego
modelu czterech routerów. Router c2600 kieruje się do sieci 212.1.1.0 zawsze przez router A, gdyż jest to tylko

jeden skok. Moglibyśmy sobie jednak wyobrazić sytuację, w której połączenie między routerem c2600 i A ma bardzo
małą przepustowość w porównaniu z poszczególnymi połączeniami na trasie "na około" przez router B. W domyślnej
konfiguracji protokół RIP jest bezradny wobec tego problemu, można jednak posłużyć się dodatkowymi poleceniami,

które sztucznie będą podnosić metrykę w protokole RIP dla pewnych, wybranych tras. Poniżej przedstawiamy
przykład konfiguracji routera c2600, w wyniku której trasa do sieci 212.1.1.0 będzie miała podnoszoną metrykę o

wartość 4. W efekcie łączna metryka przyjmie wartość 5 i będzie gorsza niż koszt trasy do sieci 212.1.1.0 przez

router B (metryka równa 3):

c2600(config)#access-list 1 permit 212.1.1.0 0.0.0.255

c2600(config)#router rip

c2600(config-router)#offset-list 1 in 4 serial0/0

Polecenie offset-list podawane w konfiguracji protokołu RIP odczytujemy następująco: dla ogłoszeń

przychodzących (in) do interfejsu Serial 0/0, które są zgodne z listą dostępu numer 1 (zdefiniowaną w poleceniu
access-list - listy dostępu omówimy w jednym z następnych artykułów), należy podnosić metrykę o wartość 4.

Zauważmy, że pokazany tutaj zapis oznacza zezwolenie (permit) dla ogłoszeń dotyczących sieci 212.1.1.0 (zapis
0.0.0.255 w tzw. odwrotnej masce oznacza, że ostatni bajt adresu sieci może być dowolny - ustawione jedynki). W

efekcie przedstawionej konfiguracji, w tabeli routingu routera c2600 pojawi się następujący wpis dla sieci 212.1.1.0:

R 212.1.1.0/24 [120/3] via 131.107.13.2, 00:00:10, Serial0/1

Oczywiście router A, przesyłając pakiety do routera c2600 (do sieci 131.108.0.0), będzie posługiwał się trasą

bezpośrednią (z metryką 1), chyba że na routerze A wprowadzimy analogiczną konfigurację dla sieci 131.108.0.0.

Protokół RIP przekazuje pełną zawartość tabeli routingu do routerów sąsiednich, stosując metodę rozgłoszeniową;

oznacza to rozsyłanie informacji do wszystkich. W pewnych sytuacjach ta domyślna konfiguracja może okazać się
rozwiązaniem nadmiarowym, a wręcz niedobrym. Wyobraźmy sobie taki układ routerów, jak na rysunku.

Chcielibyśmy, aby router c2600 przesyłał kompletną tabelę routingu do routera B, ale nie do routera A. Router
c2600 nie może więc posługiwać się metodą rozgłoszeniową, zamiast tego musi jawnie wskazać router B jako

odbiorcę (p. pokazane niżej polecenia konfiguracyjne). Polecenie passive-interface (stosowane już wcześniej)
wyłącza metodę rozgłoszeniową na wybranym interfejsie, natomiast komenda neighbor wskazuje konkretnego

sąsiada, do którego wysyłane będą informacje protokołem RIP:

C2600(config)#router rip

C2600(config-router)#passive-interface Ethernet 0/0

C2600(config-router)#neighbor 131.108.1.2

Protokół RIP w wersji 2

Protokół ten opisany jest w dokumencie RFC 1723, w porównaniu z wersją pierwszą wprowadzono w nim szereg

modyfikacji. Główną zmianą jest ogłaszanie maski podsieci razem z adresem sieci. W ten sposób w wersji drugiej
protokół RIP nadal jest protokołem wektora odległości, ale bezklasowym. Nie występuje już problem sieci
nieciągłych, można także wyłączyć automatyczne łączenie tras na granicy sieci głównych. Dzięki rozsyłaniu maski

podsieci protokół RIP w wersji drugiej obsługuje sieci VLSM (Variable Length Subnet Masking), czyli te, w których

stosuje się różnej długości maskę dla podsieci tej samej sieci głównej.

Zoptymalizowano także sposób komunikacji z routerami sąsiednimi. W wersji drugiej nadal wykorzystywany jest port
520 protokołu UDP, ale transmisja realizowana jest w drodze multiemisji z wykorzystaniem specjalnej grupy o

adresie 224.0.0.9. Dzięki temu ruch związany z protokołem RIP nie obciąża wszystkich urządzeń w danym
segmencie, a jedynie routery należące do grupy 224.0.0.9.

Wprowadzono także możliwość wzajemnego uwierzytelniania routerów wymieniających informacje. Pozwala to

wyeliminować z sieci routery nieautoryzowane, od których nie będą akceptowane ogłoszenia. Dla zapewnienia
pełnej współpracy ze starszymi urządzeniami, które posługują się tylko wersją pierwszą RIP, dodano komendy

pozwalające włączyć pełną zgodność z wersją pierwszą.

W poprzedniej sekcji wielokrotnie odwoływaliśmy się do przykładowego układu czterech routerów połączonych w
pętli. Teraz dla tego samego układu włączmy wersję drugą protokołu RIP. W tym celu należy posłużyć się

poleceniem version:

c2600(config)#router rip

c2600(config-router)#version 2

Niestety, po włączeniu wersji drugiej w tabeli routingu routera c2600 pojawia się sieć 10.0.0.0 jako 8-bitowa, choć
faktycznie na routerze B jest to sieć 24-bitowa 10.1.1.0. Oznacza to, że choć wersja druga domyślnie jest

protokołem bezklasowym, stosuje automatyczne łączenie tras na granicy sieci głównych:

R 10.0.0.0/8 [120/1] via 131.107.13.2, 00:00:04, Serial0/1

Aby ten stan zmienić, należy w konfiguracji protokołu RIP wykonać polecenie no auto-summary. Wprowadzenie

tej zmiany skutkuje nowym wpisem w tabeli routingu routera c2600:

R 10.1.1.0 [120/1] via 131.107.13.2, 00:00:01, Serial0/1

Komenda debug ip RIP może być ponownie wykorzystana do zweryfikowania działania wersji drugiej protokołu

RIP. Zwróćmy uwagę na ogłaszaną maskę podsieci oraz specjalną grupę multiemisji (224.0.0.9):

RIP: received v2 update from 131.107.13.2 on Serial0/1

05:46:17: 10.1.1.0/24 -> 0.0.0.0 in 1 hops

05:46:17: 131.107.10.0/24 -> 0.0.0.0 in 1 hops

05:46:17: 131.107.11.0/24 -> 0.0.0.0 in 2 hops

05:46:17: 196.168.2.0/24 -> 0.0.0.0 in 2 hops

05:46:17: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (131.107.13.1)

05:46:17: 131.107.11.0/24 -> 0.0.0.0, metric 2, tag 0

05:46:17: 131.107.12.0/24 -> 0.0.0.0, metric 1, tag 0

05:46:17: 212.1.1.0/24 -> 0.0.0.0, metric 2, tag 0

05:46:17: 131.108.1.0/24 -> 0.0.0.0, metric 1, tag 0

Rysunek obok przedstawia przykładowy układ czterech routerów pracujących z różnymi wersjami protokołu RIP. Aby

umożliwić routerowi A wysyłanie i odbieranie ogłoszeń przez interfejs Ethernet 0/0 zarówno dla wersji 1, jak i wersji

2, należy w konfiguracji interfejsu E 0/0 wykonać następujące polecenia:

RouterA(config-if)#ip rip send version 1 2

RouterA(config-if)#ip rip receive version 1 2

RouterA(config-if)#no ip split-horizon

Polecenie pierwsze włącza wysyłanie ogłoszeń zarówno w trybie rozgłoszeniowym (wersja 1), jak i w trybie
multiemisji (wersja 2). Polecenie drugie pozwala odbierać komunikaty z wersji pierwszej i drugiej. Komenda no ip

split-horizon (omówimy ją w dalszej części artykułu) jest tutaj niezbędna, aby router A wysyłał do routera B
informacje o sieciach, których nauczył się od routera c2600 (i odwrotnie). Ponieważ poprzez interfejs Serial 0/0

router A sąsiaduje tylko z routerem wersji pierwszej, w konfiguracji interfejsu S 0/0 należy wykonać polecenia:

RouterA(config-if)#ip rip send version 1

RouterA(config-if)#ip rip receive version 1

Proces uwierzytelniania realizowany jest w parze routerów wymieniających pakiety RIP. Opiera się na wspólnym
(identycznym) haśle zdefiniowanym na obydwu routerach. Dostępne są dwie metody przekazywania hasła między

routerami. W metodzie domyślnej hasło przesyłane jest jawnym tekstem wewnątrz pakietu RIP i niepowołane
osoby, którym uda się podsłuchać pakiety w sieci mogą to hasło odczytać. Metoda druga wymaga zastosowania

odpowiedniej komendy, jest jednak rozwiązaniem o wiele bezpieczniejszym, gdyż używa algorytmu MD5. Hasło w
tej metodzie nie jest bezpośrednio przesyłane. Na podstawie treści pakietu RIP oraz treści hasła tworzony jest,

zgodnie z algorytmem MD5, 128-bitowy podpis cyfrowy, który następnie przesyłany jest do routera sąsiedniego
razem z pakietem RIP. Router sąsiedni, znając to samo hasło, może na podstawie otrzymanego pakietu wyliczyć

samodzielnie 128-bitowy łańcuch i porównać go z podpisem otrzymanym w pakiecie.

Konfigurowanie procesu uwierzytelniania wymaga zdefiniowania zestawu kluczy, do których przypisane będą hasła
stosowane w różnych godzinach do nadawania i odbierania informacji od routera sąsiedniego. Przeanalizujmy

poniższy zestaw poleceń konfiguracyjnych na routerze c2600, włączających uwierzytelnianie metodą MD5:

2600(config)#key chain zestaw1

2600(config-keychain)#key 1

2600(config-keychain-key)#key-string cisco

2600(config-keychain-key)#accept-lifetime 08:00:00 Mar 10 2001

infinite

2600(config-keychain-key)#send-lifetime 08:00:00 Mar 10 2001

infinite

2600(config)#interface E 0/0

2600(config-if)#ip rip authentication key-chain zestaw1

2600(config-if)#ip rip authentication mode md5

W powyższym przykładzie tworzony jest zestaw kluczy o nazwie zestaw1. Nazwa ta ma znaczenie lokalne i może być

dowolna na każdym routerze. W ramach zestawu utworzono jeden klucz, któremu przypisano hasło cisco. To hasło
musi być identyczne z hasłem przypisanym do klucza na routerze sąsiednim. Dwie dodatkowe komendy accept-

lifetime oraz send-lifetime służą do określenia, kiedy dany klucz może być stosowany odpowiednio do odbierania
i wysyłania pakietów RIP. Klucz numer 1 może być wykorzystywany od godziny 8:00 10 marca 2001 i ma

nieskończoną ważność. W konfiguracji interfejsu Ethernet 0/0 włączono korzystanie z zestawu kluczy zestaw1 w
procesie uwierzytelniania komunikacji przez ten interfejs. Komenda ostatnia (nieobowiązkowa) włącza korzystanie z

metody opartej na algorytmie MD5 (domyślnie hasło przesyłane jest jawnym tekstem).

Protokół IGRP

Standardowo jeden pakiet protokołu RIP może przesłać maksymalnie 25 pozycji z tabeli routingu. Podczas stosowania metody

uwierzytelniania z przesyłaniem hasła jawnym tekstem pierwsza pozycja w pakiecie RIP zawiera hasło. W metodzie opartej na
algorytmie MD5 dwie pozycje w pakiecie RIP (pierwsza i ostatnia) zarezerwowane są na 128-bitowy podpis cyfrowy.

Protokół IGRP opracowany został przez firmę Cisco w celu wyeliminowania niektórych ograniczeń protokołu RIP.

Jedną z najważniejszych zmian jest znacznie większy dopuszczalny rozmiar sieci. W protokole RIP najdłuższa ścieżka
mogła mieć tylko 15 skoków, w protokole IGRP zwiększono tę wartość do 255 (domyślnie limit ustawiony jest na

100 skoków). Jako protokół wektora odległości i protokół klasowy IGRP podlega takim samym zasadom pracy, jak
protokół RIP i w wielu punktach jest do niego podobny. Poszczególne sieci ogłaszane są do sąsiadów przez

wszystkie włączone interfejsy z wykorzystaniem komunikacji rozgłoszeniowej. Zmieniono jednak wartości liczników

czasowych w porównaniu z protokołem RIP (ich znaczenie jest identyczne), co pokazuje poniższa tabela:

W ramach zestawu można zdefiniować kilka kluczy, które mogą być stosowane w różnym czasie, niezależnie dla trybu wysyłania i

odbierania danych. Poszczególne klucze przeglądane są kolejno (od najmniejszego numeru do największego), aż znaleziony
zostanie ten, który można wykorzystać w danym czasie przy wysyłaniu (albo odbieraniu) pakietów RIP. Opcja infinite w

poleceniach accept-lifetime i send-lifetime oznacza nieskończoną ważność klucza, począwszy od wskazanej daty. Innym
rozwiązaniem jest podanie w powyższych poleceniach daty i czasu wygasania kluczy. Można też zadeklarować czas życia kluczy od

wskazanej daty przez określoną liczbę sekund.

W porównaniu z RIP znacznie zoptymalizowano format pakietu IGRP, a protokół przenoszony jest bezpośrednio
przez warstwę IP jako protokół nr 9 (RIP wykorzystuje UDP). Kolejną ciekawą zmianą jest możliwość rozłożenia

ruchu pakietów na kilka tras o niejednakowej metryce, prowadzących do tej samej sieci. Jedną z najważniejszych
cech protokołu IGRP jest jednak zupełnie inny sposób obliczania metryki trasy. W protokole RIP koszt trasy opierał

się tylko na liczbie skoków do sieci docelowej. IGRP przesyła i monitoruje liczbę skoków, ale tylko w celu
sprawdzania, czy trasa nie jest zbyt długa (255 skoków maksymalnie). Liczba skoków nie jest w ogóle brana pod

uwagę przy wyliczaniu metryki. W zamian uwzględnia się 5 następujących parametrów:

•

Przepustowość - wartość stała definiowana w konfiguracji interfejsu, ustawiana poleceniem bandwidth.

Im większa wartość, tym bardziej preferowana trasa. Domyślnie uwzględniana w metryce.

•

Opóźnienie - wartość stała definiowana w konfiguracji interfejsu, ustawiana poleceniem delay. Im

mniejsza wartość, tym bardziej preferowana trasa. Domyślnie uwzględniana w metryce.

•

Pewność - wartość dynamicznie mierzona na poziomie interfejsu i wyrażana jako liczba z przedziału od 1
do 255. Im większa wartość (mniej błędów na interfejsie), tym bardziej preferowana trasa. Domyślnie

nieuwzględniana w metryce.

•

Obciążenie - wartość dynamicznie mierzona na poziomie interfejsu i wyrażana jako liczba z przedziału od 1

do 255. Im mniejsza liczba (mniej obciążony interfejs), tym bardziej preferowana trasa. Domyślnie
nieuwzględniana w metryce.

•

MTU - maksymalny rozmiar pola danych ramki przesyłanej w danym segmencie. Protokół IGRP śledzi

najmniejszą wartość MTU na trasie, ale obecnie w ogóle nie uwzględnia tego parametru w metryce.

Czas
Wartość

Update

od 72 do 90 sekund

Invalid

270 sekund

Hold down

280 sekund

Flush
630 sekund

Aktualne wartości powyższych parametrów wyświetlić można poleceniem show interfaces. Ponieważ Pewność i

Obciążenie są parametrami rzeczywistymi, zmieniającymi się w trakcie pracy interfejsu, oznaczałoby to również
"ciągłą" zmianę metryk. Aby temu zapobiec, wprowadzono rozwiązanie, w którym parametry te wyznaczane są z

dokładnością do 5 minut na podstawie średniej ważonej z odczytów wykonywanych co 5 sekund. Kompletny wzór,
na podstawie którego wyznacza się metrykę ma postać:

metryka = [k1*BW

IGRP(min)

+ (k2*BW

IGRP(min)

)/(256-LOAD) + k3*DLY

IGRP(sum)

] * [k5/RELIABILITY + k4]

Zwróćmy uwagę na stosowane we wzorze stałe od k1 do k5. Jeżeli stała k5 przyjmuje wartość 0, ostatni składnik

wzoru (nawias kwadratowy) nie jest w ogóle uwzględniany (wynik mnożenia zawsze byłby zerowy). Domyślnie stała

k1=k3=1, a pozostałe stałe mają wartość 0, co oznacza, że powyższy wzór przekształca się do następującego:

metryka = BW

IGRP(min)

+ DLY

IGRP(sum)

Wartości stałych od k1 do k5 można zmienić poleceniem metric weights tos k1 k2 k3 k4 k5

Składnik BWIGRP(min) oblicza się, dzieląc 107 przez najmniejszą Przepustowość na całej trasie, natomiast
DLYIGRP(sum) jest sumą opóźnień wprowadzanych przez wszystkie interfejsy wyjściowe na całej trasie wyrażoną w

dziesiątkach ms.

Wyznaczymy teraz metrykę przykładowej trasy prowadzącej z routera A do sieci 5 za routerem D (patrz rys. obok).

Najniższa przepustowość na trasie z routera A do sieci 5 wynosi 512 kb/s, stąd:

BW

IGRP(min)

= 107/512 = 19531 oraz

DLY

IGRP(sum)

= 50000/10 = 5000, czyli metryka=19531+5000=24531

Protokół IGRP konfigurujemy podobnie jak protokół RIP, za pomocą głównego polecenia konfiguracyjnego router
oraz podkomend network, których znaczenie i działanie jest takie samo, jak w protokole RIP. Zasadniczą różnicą
jest stosowanie opcji obszar w poleceniu router, wskazującej identyfikator obszaru autonomicznego, w tym

wypadku zwanego również domeną routingu. W przeciwieństwie do protokołu RIP, routery pracujące z protokołem
IGRP mogą zostać logicznie przydzielone do różnych obszarów, w ramach których wymieniane są informacje.

Standardowo routery pracujące w dwu różnych obszarach nie wymieniają informacji o sieciach. W naszym
przykładowym układzie czterech routerów połączonych w pętli (patrz str. 69), konfiguracja routera c2600 mogłaby

być taka:

c2600(config)#router IGRP 10

c2600(config-router)#network 131.107.0.0

c2600(config-router)#network 131.108.0.0

Konfiguracja pozostałych routerów będzie analogiczna. Założono, że wszystkie routery pracują w obszarze 10.
Zawartość tabeli routingu wyświetlić można poleceniem show ip route:

Gateway of last resort is not set

I 212.1.1.0/24 [100/80135] via 131.107.12.2, 00:00:21, Serial0/0

I 10.0.0.0/8 [100/80225] via 131.107.13.2, 00:00:22, Serial0/1

I 196.168.2.0/24 [100/82135] via 131.107.12.2, 00:00:22, Serial0/0

[100/82135] via 131.107.13.2, 00:00:22, Serial0/1

131.108.0.0/24 is subnetted, 1 subnets

C 131.108.1.0 is directly connected, Ethernet0/0

131.107.0.0/24 is subnetted, 4 subnets

I 131.107.10.0 [100/82125] via 131.107.13.2, 00:00:22, Serial0/1

I 131.107.11.0 [100/82125] via 131.107.12.2, 00:00:22, Serial0/0

C0 131.107.12.0 is directly connected, Serial0/0

C 131.107.13.0 is directly connected, Serial0/1

c2600#

Ponownie wyświetlane są dwie trasy do sieci 196.168.2.0 z jednakową metryką 82135. Wiarygodność protokołu

IGRP wynosi 100. Wyobraźmy sobie teraz, że na routerze c2600, w konfiguracji interfejsu Serial 0/0 zwiększono
parametr Opóźnienie, wykonując komendę delay 160000 (wartość w dziesiątkach ms). Spowoduje to zwiększenie

metryki prowadzącej do sieci 196.168.2.0 przez ten interfejs i po pewnym czasie trasa ta, jako gorsza, zostanie z
tabeli routingu usunięta. Aktualny stan parametrów wpływających na metrykę wyświetlić można dla interfejsu S0/0

poleceniem show interfaces S0/0.

Bardzo ciekawą cechą protokołu IGRP jest możliwość rozłożenia ruchu pakietów na kilka tras o różnych metrykach.
W omawianym powyżej przykładzie trasa prowadząca do sieci 196.168.2.0 przez interfejs S0/0 została usunięta z

tabeli routingu z powodu gorszej metryki. Jeśli jednak w konfiguracji protokołu IGRP na routerze c2600 zastosujemy
polecenie variance

zakres, w tabeli routingu oprócz trasy najlepszej pojawią się również te, których metryka nie

będzie niższa niż iloczyn zakresu i najlepszej metryki. W naszym przykładzie najlepsza metryka trasy przez interfejs
S0/1 wynosi 82135. Trasa przez interfejs S0/0 jest mniej niż 3 razy gorsza (zmieniono opóźnienie na 160000). Aby

w tabeli routingu pojawiły się obie trasy, należy wykonać następujące polecenia:

c2600(config)#router IGRP 10

c2600(config-router)#variance 3

Skutek obserwujemy w poleceniu sh ip route:

I 196.168.2.0/24 [100/240135] via 131.107.12.2, 00:00:16, Serial0/0

[100/82135] via 131.107.13.2, 00:00:16, Serial0/1

Jeżeli teraz na routerze c2600 włączone zostanie przełączanie pakiet po pakiecie (no ip route-cache), pakiety do
sieci 196.168.2.0 rozdzielane będą między poszczególne interfejsy w stosunku 1 do 3 (wynika to ze stosunku

metryk, a nie z komendy variance 3), co sprawdzić można po wydaniu polecenia debug ip packet. Polecenie
variance 3 oznacza, że w tabeli routingu pojawią się też trasy z metryką dwa razy gorszą od najlepszej, ale nie

cztery razy gorszą.

Po przekroczeniu dozwolonej liczby skoków, dla określonej sieci ustawia się parametr DLYIGRP na wartość
0xFFFFFF, co oznacza, iż sieć jest nieosiągalna.

Poszczególne parametry pracy protokołu IGRP (także RIP, jeśli jest włączony) wyświetlić można poleceniem show

ip protocol. Zwróćmy uwagę na parametry czasowe, wartości stałych od k1 do k5, dozwoloną rozpiętość sieci

(100), ogłaszane do sąsiadów sieci (podane klasowo), adresy sąsiadów, od których odbierane są informacje:

c2600#sh ip protocol

Routing Protocol is "igrp 10"

Sending updates every 90 seconds, next due in 9 seconds

Invalid after 270 seconds, hold down 280, flushed after 630

Outgoing update filter list for all interfaces is

Incoming update filter list for all interfaces is

Default networks flagged in outgoing updates

Default networks accepted from incoming updates

IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

IGRP maximum hopcount 100

IGRP maximum metric variance 3

Redistributing: igrp 10

Routing for Networks:

131.107.0.0

131.108.0.0

Routing Information Sources:

Gateway Distance Last Update

131.107.12.2 100 00:01:03

131.107.13.2 100 00:01:20

Distance: (default is 100)

Zapobieganie pętlom

Zarówno w sieciach wykorzystujących protokół RIP, jak i tych pracujących z protokołem IGRP może zdarzyć się, że

routery zaczną odsyłać do siebie nawzajem pakiety, sądząc, że ten drugi wie, jak dostarczyć pakiet do sieci
docelowej. Jest to przypadek pętli, która oprócz układu dwu sąsiednich routerów może obejmować swoim zasięgiem

także większe grupy routerów (są to pętle rozległe). Wprowadzono kilka mechanizmów zabezpieczających sieć przed
powstawaniem pętli. Pierwszy z nich, nazywany dzieleniem horyzontu (split horizon) oznacza, iż router nie może
ogłaszać przez konkretny interfejs sieci, których nauczył się przez ten interfejs. Tę regułę nazywamy także blokadą

ogłaszania wstecznego albo zakazem "uczenia swojego nauczyciela". Na zamieszczonym powyżej rysunku router B
otrzymuje od sąsiada ogłoszenie o sieci 13.0.0.0 przez interfejs S0. Router B nie może wysyłać informacji o sieci

13.0.0.0 z powrotem przez ten sam interfejs.

Reguła dzielenia horyzontu jest domyślnie włączona w konfiguracji interfejsów. Po jej wyłączeniu można
doprowadzić do powstania pętli między routerami, co zaobserwujemy w przykładowym układzie czterech routerów

fizycznie połączonych w pętli z włączonym protokołem RIP. Aby wyłączyć regułę dzielenia horyzontu, w konfiguracji

interfejsu należy wykonać komendę: no ip split-horizon. Skutek sprawdzamy w poleceniu sh ip int s0/0:

Serial0/0 is up, line protocol is up

Internet address is 131.107.12.1/24

Split horizon is disabled

Dla naszego przykładowego scenariusza dzielenie horyzontu należy wyłączyć w obydwu interfejsach szeregowych

routera c2600 oraz w interfejsie s0 routera A i s1 routera B (sąsiedzi routera c2600). Dodatkowo na routerze c2600
usuwamy adres IP z interfejsu Ethernet 0/0 (131.108.1.1), co spowoduje usunięcie informacji o sieci 131.108.1.0 z

tablicy routingu routera c2600. W przypadku systemu operacyjnego 11.3 router c2600 nie informuje o tym fakcie
swoich sąsiadów, którzy w efekcie przysyłają do niego informacje o sieci 131.108.0.0 ze zwiększoną metryką (równą

2). Router c2600 musi te informacje zaakceptować, gdyż nie ma innych, lepszych i sam ogłasza sieć 131.108.0.0 do
sąsiadów, ponownie zwiększając liczbę skoków (3). Routery A i B również muszą to ogłoszenie zaakceptować (mimo

że zwiększa się metryka), gdyż router c2600 jest oryginalnym nauczycielem, od którego dowiedziały się o sieci
131.108.0.0. Tak powstaje pętla, na skutek której pakiety do sieci 131.108.0.0 router c2600 kierować będzie do
routera A, a router A odsyłać będzie do c2600. W kolejnych cyklach czasowych, sieć 131.108.0.0 jest ogłaszana z

coraz większą metryką, co bardzo dobrze można zaobserwować po uruchomieniu procesu śledzenia deb ip RIP na

routerze c2600:

08:29:45: RIP: sending v1 update to 255.255.255.255 via Serial0/1 (131.107.13.1)

08:29:45: network 131.108.0.0, metric 9

08:29:47: RIP: received v1 update from 131.107.13.2 on Serial0/1

08:29:47: 131.108.0.0 in 10 hops

Dla powyższych ogłoszeń zawartość tabeli routingu routera c2600 będzie następująca:

R 131.108.0.0/16 [120/10] via 131.107.13.2, 00:00:01, Serial0/1

W przypadku protokołu RIP pętla dla sieci 131.108.0.0 automatycznie się skończy po przekroczeniu dozwolonej

liczby skoków (15), gdyż sieć ta zostanie oznaczona jako nieosiągalna (z metryką równą 16).

Pętle rozległe powstające w większej grupie routerów eliminuje się poprzez regułę dzielenia horyzontu z
zatruwaniem wstecznym (split horizon with poisoned reverse). W przeciwieństwie do zwykłej reguły dzielenia

horyzontu, tym razem zezwala się na ogłaszanie wsteczne, ale tylko w bardzo specyficznych sytuacjach. Wyobraźmy
sobie parę routerów, w której router A regularnie ogłasza do routera B pewną sieć, za każdym jednak razem

zwiększając metrykę tej trasy (co może być skutkiem powstania pętli w innej części sieci). Router B "zgadza się" na
pierwsze podniesienie metryki przez router A, ale przy kolejnym ogłoszeniu z ponownie większą metryką router B
"domyśla się", iż w sieci powstała pętla i "zatruwa" trasę poprzez wysłanie ogłoszenia z powrotem do routera A, ale

z metryką oznaczającą sieć nieosiągalną (16 dla protokołu RIP).

Powróćmy teraz do scenariusza omawianego powyżej, w którym wyłączono dzielenie horyzontu między routerem

c2600 i jego sąsiadami (między tymi routerami automatycznie wyłączone jest też zatruwanie wsteczne). W tym

scenariuszu doprowadziliśmy do powstania pętli między routerem c2600 i jego sąsiadami, a skutek tego przenosi się
również na router C. Między routerem A i C włączone jest dzielenie horyzontu oraz zatruwanie wsteczne. Router A
zaczyna ogłaszać sieć 131.108.0.0 do routera C z coraz większą metryką. Przy drugim podniesieniu metryki router C

zatruwa trasę do sieci 131.108.0.0, wysyłając do routera A ogłoszenie z metryką 16. Router A otrzymuje więc

informację, że do sieci 131.108.0.0 na pewno nie można pójść przez router C:

08:34:49: RIP: sending v1 update to 255.255.255.255 via Serial1 (131.107.11.2)

08:34:49: RIP: build update entries

08:34:49: network 131.108.0.0 metric 16

Kolejny mechanizm, którego celem jest przyspieszenie aktualizacji tabel routingu, to tzw. aktualizacja wymuszona

(triggered update). Niezależnie od regularnych czasów aktualizacji (około 30 sekund dla protokołu RIP) router
wysyła natychmiastowo do swoich sąsiadów informacje o sieci, dla której zmieniła się metryka (na lepszą bądź

gorszą). Aktualizacja wymuszona przesyła tylko tę sieć, dla której zmieniła się metryka, a nie całą tabelę routingu,
nie zakłóca też terminarza aktualizacji regularnych.

Przykładem aktualizacji wymuszonej jest włączenie polecenia shutdown w konfiguracji interfejsu. Sieć IP tego

interfejsu jest natychmiastowo usuwana z tabeli routingu, a do sąsiadów wysyłane jest ogłoszenie, iż sieć ta jest
nieosiągalna. W zależności od systemu operacyjnego ogłaszana sieć zostanie od razu usunięta z tabeli routingu

innych routerów bądź ustawiona w tryb przytrzymywania (hold down). Pamiętajmy, że usunięcie adresu IP z
interfejsu routera z systemem operacyjnym 11.3 nie powoduje aktualizacji wymuszonej (w wersji 12.0 już tak).

Redystrybucja danych routingu

Proces redystrybucji danych o routingu między różnymi źródłami informacji najczęściej konfiguruje się w

środowisku, w którym uruchomione są różne protokoły routingu dynamicznego. Jego celem jest przekazanie
informacji o sieciach zebranych w ramach jednego protokołu do innego protokołu routingu dynamicznego. Można

sobie wyobrazić rozbudowaną sieć, w której część urządzeń pracuje z wykorzystaniem protokołu RIP, a pozostała
część korzysta z protokołu IGRP. Dzięki redystrybucji wszystkie routery będą posiadały informacje o wszystkich

segmentach sieci.

Specyficzną odmianą procesu redystrybucji jest rozgłaszanie tras statycznych przy wykorzystaniu protokołu routingu
dynamicznego. Poprzez redystrybucję realizuje się także wymianę danych między różnymi obszarami w ramach

protokołu IGRP. Podstawowym problemem przy przekazywaniu informacji z jednego źródła do innego jest zmiana
metryki. Nie można bowiem przenieść tras z protokołu RIP, gdzie metryka to liczba skoków mniejsza niż 16, do

protokołu IGRP, w którym koszt trasy wyznaczany jest według zupełnie innych kryteriów. W trakcie konfigurowania
procesu redystrybucji w ramach określonego protokołu routingu dynamicznego należy podać wartość metryki, jaką

będą otrzymywały wszystkie pobierane z innego źródła trasy. Prześledzimy teraz scenariusz, w którym router c2600
będzie realizował redystrybucję między protokołem RIP oraz IGRP (patrz rysunek).

Przykład redystrybucji między RIP a IGRP

Sieć z lewej strony routera c2600 (interfejs S0/0 oraz router A) korzysta z protokołu RIP, sieć z prawej strony
(interfejs S0/1 oraz router B) stosuje protokół IGRP. Redystrybucję włącza się na routerze brzegowym dla kilku

źródeł informacji; w tym wypadku jest to router c2600, na którym uruchomiono zarówno protokół RIP, jak i IGRP.
Podstawowym poleceniem konfiguracyjnym jest komenda redistribute parametr wykonywana wewnątrz procesu,

do którego dane pobierane są z zewnętrznego źródła wskazanego jako parametr. Przykładowa konfiguracja routera
c2600 mogłaby być następująca:

c2600(config)#router rip

c2600(config-router)#redistribute igrp 10 metric 5

c2600(config-router)#passive-interface Serial 0/1

c2600(config-router)#network 131.107.0.0

c2600(config)#router igrp 10

c2600(config-router)#redistribute rip

c2600(config-router)#default-metric 1000 100 255 1 1500

c2600(config-router)#passive-interface Serial 0/0

c2600(config-router)#network 131.107.0.0

Zwróćmy uwagę na dwa sposoby określania metryki dla pobieranych tras. Metrykę można zdefiniować, stosując
opcję metric w komendzie redistribute. W powyższym przykładzie trasy pobierane do protokołu RIP z obszaru 10

protokołu IGRP będą miały metrykę 5. Można także zdefiniować domyślną metrykę dla wszystkich poleceń
redistribute, stosując komendę default-metric z odpowiednimi parametrami. W powyższym przykładzie

polecenie default-metric wymagało aż pięciu parametrów, z których liczona jest metryka w protokole IGRP
(Przepustowość, Opóźnienie, Pewność, Obciążenie, MTU). Dla protokołu RIP wymagany jest tylko jeden parametr -

liczba skoków. Polecenie passive-interface blokuje ogłaszanie danego protokołu przez wskazany interfejs.
Gdybyśmy dodatkowo chcieli w ramach protokołu RIP ogłaszać trasy statycznie wpisane do tabeli routingu routera

c2600, należałoby wykonać następujące polecenie:

c2600(config)#router rip

c2600(config-router)#redistribute static metric 5

Na zakończenie skonfigurujmy redystrybucję między dwoma obszarami protokołu IGRP pokazanymi na rysunku.
Ponieważ tym razem redystrybucja dotyczy tego samego protokołu, nie występuje tutaj problem zmiany metryki.

Przykład redystrybucji między dwoma obszarami IGRP

Konfiguracja routera c2600 będzie następująca:

c2600(config)#router igrp 10

c2600(config-router)#redistribute igrp 20

c2600(config)#router igrp 20

c2600(config-router)#redistribute igrp 10

* * *

Następny artykuł dotyczyć będzie filtrowania ruchu przechodzącego przez router, przy wykorzystaniu list dostępu.

Autorzy są instruktorami i inżynierami systemowymi w firmie DC Edukacja (adresy e-mail:

[e-mail]

i

[e-mail]

). Firma DC Edukacja specjalizuje w szkoleniach technicznych

dla administratorów i inżynierów Microsoft i Cisco, przeprowadza również egzaminy VUE i Prometric. Posiada ośrodki

szkoleniowe w Warszawie, Wrocławiu, Gdańsku i Kielcach.