CCNA Exploration - Protokoły i koncepcje routingu

5 Protokół RIPv1

5.0 Routing Information Protocol

5.0.1 Wprowadzenie do rozdziału

Strona 1:

Protokoły routingu od lat ewoluują, aby zaspokoić wzrastające wymagania złożonych sieci. Pierwszym używanym protokołem był Routing Information Protocol (RIP). RIP nadal cieszy się popularnością ze względu na swoją powszechność i prostotę obsługi.

Zrozumienie działania protokołu RIP jest ważne z dwóch powodów: RIP jest dziś nadal używany. Spotykane są jeszcze sieci na tyle duże, że potrzebują protokołu routingu, a zarazem na tyle proste, aby efektywnie używać protokołu RIP. Znajomość wielu fundamentalnych koncepcji protokołu RIP ułatwi porównanie protokołu RIP z innymi protokołami. Zrozumienie działania protokołu RIP i poznanie jego implementacji ułatwią uczenie się innych protokołów.

W tym rozdziale omówiono szczegóły wersji 1 protokołu RIP, w tym trochę historii, cechy charakterystyczne protokołu RIP, działanie, konfigurację, sprawdzanie i rozwiązywanie problemów. W trakcie lektury całego rozdziału można wykonywać zadania Packet Tracer, aby na bieżąco ćwiczyć omawiane umiejętności. Na końcu tego rozdziału znajdują się trzy ćwiczenia do wykonania w pracowni komputerowej oraz zadanie Packet Tracer Skills Integration Challenge, które pomogą przyswoić nowe informacje z zakresu sieci komputerowych.

5.1 RIPv1: klasowy protokół routingu wektora odległości

5.1.1 Przeszłość i znaczenie

Strona 1:

Historyczny wpływ RIP

RIP to najstarszy protokół routingu wektora odległości. Mimo że brakuje mu złożoności bardziej zaawansowanych protokołów routingu, prostota i ciągła popularność świadczą o jego trwałości. I nigdzie się nie wybiera. Istnieje nawet forma protokołu RIP dla IPv6 o nazwie RIPng (next generation).

Kliknij daty na ilustracji, aby porównać rozwój sieci i protokołu RIP w czasie.

Protokół RIP rozwinął się z opracowanego wcześniej w firmie Xerox protokołu o nazwie GWINFO (Gateway Information Protocol). Wraz z rozwojem systemu XNS (Xerox Network System) GWINFO przekształcił się w RIP. Późniejszą popularność zawdzięcza temu, że został zaimplementowany w systemie BSD (Berkeley Software Distribution) jako demon o nazwie routed (wymawia się nie ruted, ale rutdi). Wielu producentów stworzyło własne, nieco odmienne implementacje protokołu RIP. Zauważając potrzebę normalizacji tego protokołu, w 1988 roku Charles Hedrick w dokumencie RFC 1058 zdefiniował istniejący protokół wraz z udoskonaleniami. Od tego czasu powstały jeszcze dwie wersje: RIPv2 w 1994 roku i RIPng w 1997 roku.

Uwaga: Pierwsza wersja protokołu RIP, w celu odróżnienia od wersji drugiej (RIPv2), jest często nazywana RIPv1. Niemniej obie wersje mają wiele tych samych cech. Omawiając cechy wspólne dla obu wersji, będziemy odnosić się do RIP. Omawiając funkcje unikatowe dla każdej wersji, będziemy używać akronimów RIPv1 i RIPv2. Protokół RIPv2 omówiono późniejszym rozdziale.

5.1.2 Cechy protokołu i format komunikatów RIPv1

Strona 1:

Cechy protokołu RIP

Jak wyjaśniono w rozdziale 4 „Protokoły routingu wektora odległości”, najważniejsze cechy protokołu RIP to:

• RIP to protokół routingu wektora odległości,

• RIP jako jedynej metryki przy wyborze drogi używa liczby skoków,

• trasy ogłaszane z licznikiem skoków powyżej 15 są uznawane za nieosiągalne,

• komunikaty odpowiedzi (aktualizacje tablicy routingu) są wysyłane jako rozgłoszenie co 30 sekund.

Wskaż odpowiednie pola na enkapsulowanym komunikacie RIPv1, aby zobaczyć proces enkapsulacji.

Część z danymi komunikatu RIP jest enkapsulowana w segmencie UDP (User Data-gram Protocol), a źródłowy i docelowy numer portu to 520. Nagłówek IP i nagłówki łącza danych dodają rozgłoszeniowe adresy docelowe, zanim komunikat zostanie wysłany ze wszystkich interfejsów, na których skonfigurowano protokół RIP.

Strona 2:

Format komunikatu RIP: nagłówek RIP

W czterobajtowym nagłówku trzy pola zostały wyróżnione pomarańczowym kolorem. W polu Polecenie określony jest typ komunikatu, omówiony dokładniej w kolejnym podrozdziale. Pole Wersja ma wartość 1 w przypadku protokołu RIPv1. Trzecie pole zostało opisane „musi być zero”. Pola "musi być zero” są zarezerwowane na rozbudowę protokołu w przyszłości.

Format komunikatu RIP: wpis trasy

Część komunikatu z wpisem trasy zawiera trzy pola z zawartością: identyfikator rodziny adresów (2 dla IP, chyba że żądanie dotyczy pełnej tablicy routingu - wówczas pole jest ustawione na 0), adres IP, metryka. Ten fragment wpisu trasy reprezentuje jedną trasę docelową ze skojarzoną metryką. Jedna aktualizacja RIP może zawierać do 25 wpisów tras. Maksymalny rozmiar datagramu to 512 bajtów, nie licząc nagłówków IP i UDP.

Dlaczego tak wiele pól jest ustawionych na zero?

Protokół RIP powstał przed protokołem IP i był używany do innych protokołów sieciowych (jak XNS). Wpływ widoczny jest również w BSD. Początkowo puste miejsce zostało dodane z myślą o obsłudze większej przestrzeni adresowej w przyszłości. Jak się przekonamy w rozdziale 7, protokół RIPv2 wykorzystuje teraz większość tych pustych pól.

5.1.3 Działanie protokołu RIP

Strona 1:

Proces żądania i odpowiedzi RIP

RIP wykorzystuje dwa typy komunikatów określone w polu Polecenie: komunikaty żądania i komunikaty odpowiedzi.

Kliknij Odtwórz, aby zobaczyć proces żądania i odpowiedzi.

Każdy interfejs, na którym skonfigurowano protokół RIP, po uruchomieniu wysyła komunikat Żądanie, żądając, aby wszyscy sąsiedzi wysłali swoje pełne tablice routingu. Sąsiedzi z włączonym protokołem RIP odsyłają komunikat Odpowiedź. Kiedy router odbiera odpowiedzi, ocenia każdy wpis trasy. Jeśli wpis trasy jest nowy, router odbierający instaluje trasę w tablicy routingu. Jeśli trasa już się znajduje w tej tablicy, ale w nowym wpisie jest mniejsza liczba skoków, istniejący wpis zostaje zastąpiony. Pierwszy router następnie wysyła ze wszystkich interfejsów z protokołem RIP aktualizację wyzwalaną z własną tablicą routingu, aby poinformować sąsiadów RIP o wszystkich nowych trasach.

Strona 2:

Klasy adresów IP i routing klasowy

Z poprzednich kursów wiemy, że adresy IP przypisywane hostom były początkowo podzielone na trzy klasy: A, B i C. Każda klasa miała domyślnie przypisaną maskę, tak jak pokazano na ilustracji. Aby zrozumieć działanie protokołu RIP, trzeba znać domyślną maskę każdej klasy.

RIP to klasowy protokół routingu. Jak można wywnioskować na podstawie formatu komunikatów, RIPv1 w aktualizacjach nie wysyła informacji o masce podsieci. Tym samym router albo używa maski podsieci skonfigurowanej na lokalnym interfejsie, albo stosuje domyślną maskę podsieci na podstawie klasy adresu. Ze względu na to ograniczenie sieci RIPv1 nie mogą być nieciągłe, nie można też implementować w nich VLSM.

Adresowanie IP omówiono dokładniej w rozdziale 6, "VLSM i CIDR". Możesz również przeglądnąć odsyłacze w celu powtórzenia klas adresów.

5.1.4 Odległość administracyjna

Strona 1:

Jak wyjaśniono w rozdziale 3 „Wprowadzenie do protokołów routingu dynamicznego”, odległość administracyjna (ang. administrative distance) to wiarygodność (albo priorytet) źródła trasy. Domyślna odległość administracyjna protokołu RIP wynosi 120. W porównaniu z innymi protokołami bramy wewnętrznej RIP to protokół routingu z najniższym priorytetem. Protokoły IS-IS, OSPF, IGRP, EIGRP mają niższe domyślne wartości odległości administracyjnej

Jak pamiętamy, odległość administracyjną można sprawdzić, wydając polecenie show ip route albo polecenie show ip protocols.

5.2 Podstawowa konfiguracja protokołu RIPv1

5.2.2 Włączanie protokołu RIP - polecenie router rip

Strona 1:

Aby włączyć protokół routingu dynamicznego, wchodzimy w tryb konfiguracji globalnej i wydajemy polecenie router. Jak pokazano na ilustracji, jeśli po poleceniu wpiszemy spację i znak zapytania, wyświetlona zostanie lista wszystkich dostępnych protokołów routingu obsługiwanych przez system IOS.

Aby wejść w tryb konfiguracji routera dla protokołu RIP, po znaku gotowości konfiguracji globalnej wpisujemy router rip. Zwróćmy uwagę, że znak gotowości wiersza poleceń zmienia się ze znaku konfiguracji globalnej na poniższy:

R1(config-router)#

Polecenie to nie rozpoczyna bezpośrednio procesu RIP. Daje natomiast dostęp do konfiguracji ustawień tego protokołu. Do czasu skonfigurowania dodatkowych poleceń żadne aktualizacje routingu nie są wysyłane.

Jeśli zajdzie konieczność usunięcia procesu routingu RIP z urządzenia, należy zanegować to polecenie, wpisując no router rip. Polecenie to zatrzymuje proces RIP i wymazuje wszystkie istniejące polecenia konfiguracyjne RIP.

5.2.3 Określanie sieci

Strona 1:

Po wejściu w tryb konfiguracji routera RIP router może używać tego protokołu. Ale wcześniej musi się dowiedzieć, których interfejsów lokalnych powinien używać w komunikacji z innymi routerami, jak również które sieci połączone lokalnie powinien ogłaszać tym routerom. Aby włączyć routing RIP dla sieci, w trybie konfiguracji routera wydajemy polecenie network i wprowadzamy adres sieci klasowej dla każdej sieci połączonej bezpośrednio.

Router(config-router)#network adres sieci połączonej bezpośrednio

Polecenie network:

• Włącza protokół RIP na wszystkich interfejsach, które należą do określonej sieci. Interfejsy te zaczynają od tego momentu zarówno wysyłać, jak i odbierać aktualizacje RIP.

• Ogłasza określoną sieć w aktualizacjach routingu RIP wysyłanych do innych routerów co 30 sekund.

Uwaga: Jeśli wprowadzimy adres podsieci, system IOS automatycznie konwertuje go do klasowego adresu sieciowego. Na przykład, jeśli wpiszemy polecenie network 192.168.1.32, router zmieni to polecenie na network 192.168.1.0.

Strona 2:

Na ilustracji widzimy polecenie network skonfigurowane na wszystkich trzech routerach dla sieci połączonych bezpośrednio. Należy zwrócić uwagę, że wprowadzone zostały

tylko sieci klasowe.

Co się stanie, kiedy używając polecenia network dla konfiguracji protokołu RIP, zamiast klasowego adresu sieciowego wpiszemy adres podsieci albo adres IP interfejsu?

R3(config)#router rip
R3(config-router)#network 192.168.4.0
R3(config-router)#network 192.168.5.1

W tym przykładzie zamiast klasowego adresu sieci wprowadzono adres IP interfejsu. Zwróćmy uwagę, że system IOS nie wyświetla komunikatu o błędzie. Natomiast koryguje wprowadzone dane i wprowadza klasowy adres sieciowy. Co widzimy w poniższych wynikach.

R3# show running-config
!
router rip
network 192.168.4.0
network 192.168.5.0
!

5.3 Weryfikacja i rozwiązywanie problemów

5.3.1 Weryfikacja protokołu RIP: polecenie show ip route

Strona 1:

Przydatne polecenia rozwiązywania problemów

Aby sprawdzić i zdiagnozować routing, najpierw używamy poleceń show ip route i show ip protocols. Jeśli nie uda się wyodrębnić problemów za pomocą tych dwóch poleceń, wydajemy polecenie debug ip rip, aby zobaczyć, co tak naprawdę się dzieje. Te trzy polecenia są omówione w zalecanej kolejności używania ich podczas rozwiązywania problemów z konfiguracją protokołu routingu. Przypominamy, że przed skonfigurowaniem jakiegokolwiek routingu - statycznego albo dynamicznego - wydajemy polecenie ip interface brief, aby upewnić się, że wszystkie wymagane interfejsy są włączone.

Kliknij R1, R2 oraz R3, aby zobaczyć ich tablice routingu.

Polecenie show ip route sprawdza, czy trasy odebrane przez sąsiadów RIP zostały zainstalowane w tablicy routingu. Litera R w wynikach oznacza trasy RIP. Ponieważ polecenie to wyświetla całą tablicę routingu, w tym trasy połączone bezpośrednio i statyczne, jest z reguły pierwszym poleceniem używanym do sprawdzania zbieżności. Na wyświetlenie tras niekiedy trzeba trochę poczekać, ponieważ sieci potrzebują czasu na osiągnięcie stanu zbieżności. Jednak jeśli na wszystkich routerach routing został skonfigurowany prawidłowo, w wynikach polecenia show ip route zobaczymy, że każdy router ma kompletną tablicę routingu, z trasami do każdej sieci w topologii.

Kliknij na przycisk Topologii

Jak widzisz na ilustracji, w topologii znajduje się pięć sieci. Każdy router ma w tablicy routingu pięć sieci. Tym samym można powiedzieć, że wszystkie trzy routery są zbieżne, ponieważ każdy router zna trasę do każdej sieci pokazanej w topologii.

Strona 2:

Interpretowanie wyników polecenia show ip route:

Aby lepiej zrozumieć wyniki polecenia show ip route, skupimy się na jednej trasie RIP znalezionej przez router R1 i zinterpretujemy wyniki pokazane w tablicy routingu.

R 192.168.5.0/24 [120/2] via 192.168.2.2, 00:00:23, Serial0/0/0

Wyświetlenie tras z kodem R to szybki sposób, aby sprawdzić, czy protokół RIP działa na danym routerze. Jeśli protokół RIP nie jest skonfigurowany przynajmniej częściowo, nie zobaczymy tras RIP.

Następnie wymienione są adres sieci i maska podsieci (192.168.5.0/24).

W nawiasie kwadratowym widzimy wartość odległości administracyjnej (120 dla protokołu RIP) oraz odległość do sieci (2 skoki).

Dalej widzimy adres IP następnego skoku ogłaszającego routera (R2 i 192.168.2.2), a także liczbę sekund, które upłynęły od czasu ostatniej aktualizacji (w tym przypadku 00:00:23).

Na końcu widzimy interfejs wyjściowy, którego ten router będzie używał do przesy-łania ruchu przeznaczonego do zdalnej sieci (Serial 0/0/0).

5.3.2 Sprawdzanie protokołu RIP: polecenie show ip protocols

Strona 1:

Interpretowanie wyniku działania polecenia show ip protocols

Jeśli w tablicy routingu brakuje trasy, sprawdzamy konfigurację routingu za pomocą polecenia show ip protocols. Polecenie show ip protocols wyświetla protokół routingu, który jest w danej chwili skonfigurowany na routerze. W wynikach można zobaczyć wiele parametrów RIP i w ten sposób sprawdzić, czy:

• routing RIP jest skonfigurowany,

• pawidłowe interfejsy wysyłają i odbierają aktualizacje RIP,

• router ogłasza prawidłowe sieci,

• sąsiedzi RIP wysyłają aktualizacje.

Polecenie to jest przydatne również podczas sprawdzania działania innych protokołów routingu, o czym się przekonamy, omawiając EIGRP oraz OSPF.

Kliknij przycisk 1 na ilustracji.

Pierwszy wiersz wyników potwierdza, że routing RIP został skonfigurowany i działa na routerze R2. Jak wyjaśniono w podrozdziale „Podstawowa konfiguracja protokołu RIPv1”, zanim protokół RIP będzie mógł rozpocząć działanie, potrzebny jest co najmniej jeden aktywny interfejs z poleceniem network.

Kliknij przycisk 2 na ilustracji.

Liczniki pokazujące, kiedy z tego routera zostanie wysłana kolejna partia aktualizacji - w tym przykładzie stanie się to za 23 sekundy.

Kliknij przycisk 3 na ilustracji.

Ta informacja wiąże się z filtrowaniem aktualizacji i redystrybucją tras, jeśli zostało to skonfigurowane na tym routerze. Filtrowanie i redystrybucja to zagadnienia oma-wiane na kursach CCNP.

Kliknij przycisk 4 na ilustracji.

W tym bloku wyników znajdują się informacje o tym, która wersja protokołu RIP jest w danej chwili skonfigurowana i które interfejsy biorą udział w wymianie aktualizacji RIP.

Kliknij przycisk 5 na ilustracji.

W tej części wyników widzimy, że router R2 obecnie sumuje trasy na granicy sieci klasowej i domyślnie rozkłada ruch na maksymalnie cztery równorzędne trasy. Pod-sumowanie automatyczne jest omówione w dalszej części tego rozdziału.

Kliknij przycisk 6 na ilustracji.

Niżej wymienione są sieci klasowe skonfigurowane za pomocą polecenia network. Są to sieci, które router R2 będzie umieszczał w swoich aktualizacjach RIP.

Kliknij przycisk 7 na ilustracji.

Przewiń, aby zobaczyć dalsze wyniki. Tutaj jako źródła informacji o trasach wymienieni są sąsiedzi RIP. Brama to adres IP sąsiada następnego skoku, który wysyła aktualizacje R2. Odległość to odległość administracyjna, której R2 używa do aktualizacji wysyłanych przez tego sąsiada. Ostatnia aktualizacja (Last Update) to sekundy od czasu otrzymania ostatniej aktualizacji od tego sąsiada.

5.3.3 Sprawdzanie protokołu RIP: polecenie debug ip rip

Strona 1:

Interpretowanie wyniku działania polecenia debug ip rip

Większość błędów konfiguracyjnych z protokołem RIP wiąże się z nieprawidłową konfiguracją instrukcji network, brakiem konfiguracji instrukcji network albo konfiguracją sieci nieciągłych w środowisku klasowym. Jak widzimy na ilustracji, efektywnym poleceniem używanym do wyszukiwania problemów z aktualizacjami RIP jest debug ip rip. To polecenie wyświetla aktualizacje routingu RIP w czasie ich wysyłania i odbierania. Ponieważ aktualizacje są okresowe, przed zobaczeniem jakichkolwiek wyników trzeba poczekać na kolejną partię aktualizacji.

Kliknij przycisk 1 na ilustracji.

Na początku widzimy aktualizację, która pojawiła się na interfejsie Serial 0/0/0 od routera R1. Zwróćmy uwagę, że router R1 wysyła tylko jedną trasę do sieci 192.168.1.0. Inne trasy nie są wysyłane, ponieważ byłoby to naruszeniem reguły podzielonego horyzontu. Routerowi R1 nie wolno ogłaszać routerowi R2 tych sieci, o których dowiedział się właśnie od niego.

Kliknij przycisk 2 na ilustracji.

Kolejna aktualizacja, która została odebrana od routera R3. Tutaj też ze względu na podzielony horyzont router R3 wysyła tylko jedną trasę - sieć 192.168.5.0.

Kliknij przycisk 3 na ilustracji.

Router R2 wysyła własne aktualizacje. Najpierw konstruuje aktualizację, która zostanie wysłana z interfejsu FastEthernet 0/0. Aktualizacja ta zawiera całą tablicę routingu oprócz sieci 192.168.3.0, która jest podłączona do interfejsu FastEthernet 0/0.

Kliknij przycisk 4 na ilustracji.

Następnie router R2 konstruuje aktualizację dla routera R3. Znajdują się w niej trzy trasy. R2 nie ogłasza sieci wspólnej z routerem R3, ze względu na podzielony horyzont nie ogłasza również sieci 192.168.5.0.

Kliknij przycisk 5 na ilustracji.

Następnie R2 konstruuje aktualizację, która zostanie wysłana do routera R1. Znajdują się w niej trzy trasy. R2 nie ogłasza sieci wspólnej dla R2 i R3, ze względu na podzielony horyzont nie ogłasza również sieci 192.168.1.0.

Uwaga: Odczekawszy kolejnych 30 sekund, zobaczymy raz jeszcze te same wyniki co na rysunku, ponieważ RIP wysyła aktualizacje okresowe co 30 sekund.

Kliknij przycisk 6 na ilustracji.

Aby zakończyć monitorowanie aktualizacji RIP na routerze R2, wydajemy polecenie no debug ip rip albo po prostu undebug all, tak jak na rysunku.

Przeglądając ten wynik debugowania, można stwierdzić, że routing RIP na routerze R2 działa bez zarzutu. Ale czy jest jakiś sposób, aby zoptymalizować routing RIP na routerze R2? Czy router ten musi wysyłać aktualizacje z interfejsu FastEthernet 0/0? W kolejnym podrozdziale dowiemy się, jak uniknąć wysyłania zbędnych aktualizacji.

5.3.4 Interfejsy pasywne

Strona 1:

Zbędne aktualizacje RIP przeciążają sieć

Jak widzieliśmy w poprzednim przykładzie, router R2 wysyła aktualizacje z interfejsu FastEthernet 0/0, mimo że w tej sieci LAN nie ma żadnego routera. Router R2 nie ma o tym pojęcia i w efekcie wysyła aktualizacje co 30 sekund. Wysyłanie zbędnych aktualizacji wpływa na sieć na trzy sposoby.

1. Szerokość pasma marnuje się na transport zbędnych aktualizacji. Ponieważ aktualizacje RIPv1 to komunikaty rozgłoszeniowe, przełączniki przekazują je ze wszystkich portów.

2. Wszystkie urządzenia w sieci lokalnej muszą przetworzyć aktualizację RIPv1 aż do warstwy transportu, w której urządzenie odbierające odrzuca aktualizację.

3. Ogłaszanie aktualizacji w sieci rozgłoszeniowej to zagrożenie dla bezpieczeństwa. Aktualizacje RIP można przechwycić za pomocą oprogramowania do podsłuchiwania pakietów. Aktualizacje routingu można zmodyfikować i odesłać do routera, uszkadzając tablicę routingu przez podanie fałszywych metryk, przez co ruch będzie źle kierowany.

Zatrzymywanie zbędnych aktualizacji RIP

Wydawałoby się, że zatrzymanie aktualizacji wymaga usunięcia sieci 192.168.3.0 z konfiguracji za pomocą polecenia no network 192.168.3.0, ale wówczas router R2 nie ogłaszałby tej sieci LAN w aktualizacjach wysyłanych do routera R1 i R3. Prawidłowym rozwiązaniem jest wydanie polecenia passive-interface, które zapobiega transmisji aktualizacji routingu przez interfejs routera, ale pozwala w dalszym ciągu ogłaszać daną sieć innym routerom. Polecenie passive-interface wydajemy w trybie konfiguracji routera:

Router(config-router)# passive-interface typ-interfejsu numer-interfejsu

To polecenie zatrzymuje wysyłanie aktualizacji routingu na określonym interfejsie. Jednak sieć, do której ten interfejs należy, nadal będzie ogłaszana w aktualizacjach routingu, które są wysyłane z innych interfejsów.

Na ilustracji na routerze R2 najpierw konfigurujemy z polecenie passive-inter-face, aby wyłączyć aktualizacje routingu na interfejsie FastEthernet 0/0, ponieważ w tej sieci LAN nie ma żadnych sąsiadów RIP. Następnie do sprawdzenia pasywnego interfejsu używamy polecenia show ip protocols. Zwróćmy uwagę, że interfejs nie pojawia się już pod hasłem Interface, ale w nowej sekcji o nazwie Passive Interface(s). Poza tym sieć 192.168.3.0 nadal znajduje się pod hasłem Routing for Networks, co oznacza, że ta sieć wciąż jest dołączana jako wpis trasy w aktualizacjach RIP, które są wysyłane do routerów R1 i R3.

Wszystkie protokoły routingu obsługują polecenie passive-interface. Jeśli polecenie passive-interface jest wymagane, używamy go w normalnej konfiguracji routingu.

5.4 Automatyczne podsumowanie

5.4.1 Zmodyfikowana topologia: scenariusz B

Strona 1:

Aby ułatwić omawianie automatycznego podsumowania, będziemy posługiwać się topologią RIP pokazaną na rysunku.

Używane są trzy sieci klasowe:

• 172.30.0.0/16

• 192.168.4.0/24

• 192.168.5.0/24

Sieć 172.30.0.0 jest podzielona na trzy podsieci:

• 172.30.1.0/24

• 172.30.2.0/24

• 172.30.3.0/24

Częścią klasowego adresu sieciowego 172.30.0.0/16 są następujące urządzenia:

• wszystkie interfejsy routera R1,

• interfejsy S0/0/0 i Fa0/0 routera R2.

Z sieci 192.168.4.0/24 jest wydzielona jedna podsieć - 192.168.4.8/30.

Strona 2:

Kliknij R1, R2 i R3, aby przejrzeć szczegóły konfiguracji

Zwróćmy uwagę, że polecenia no shutdown i clock rate nie są potrzebne, ponieważ zostały już skonfigurowane w scenariuszu A. Zostały jednak dodane nowe sieci, dlatego proces routingu RIP przed ponownym włączeniem został usunięty za pomocą polecenia no router rip.

Kliknij R1 na ilustracji.

W konfiguracji routera R1 obie podsieci zostały skonfigurowane za pomocą polecenia network. Ta konfiguracja jest z technicznego punktu widzenia nieprawidłowa, ponieważ RIPv1 wysyła w swoich aktualizacjach adres sieci klasowej, a nie podsieć. Dlatego też system IOS zmienił konfigurację, aby była zgodna z prawidłową konfiguracją klasową, co widzimy w wynikach polecenia show run.

Kliknij R2 na ilustracji.

W konfiguracji routera R2 zauważ, że podsieć 192.168.4.8 została skonfigurowana z użyciem polecenia network. Ta konfiguracja również jest z technicznego punktu widzenia nieprawidłowa, więc system IOS zmienił ją w konfiguracji bieżącej na 192.168.4.0.

Kliknij R3 na ilustracji.

Informacja o trasach dla routera R3 jest prawidłowa. Konfiguracja bieżąca zgadza się z tym, co zostało wprowadzone w trybie konfiguracji routera.

Uwaga: W egzaminach końcowych i certyfikacyjnych wpisanie adresu podsieci zamiast klasowego adresu sieci w poleceniu network jest uznawane jako błąd.

5.4.2 Routery brzegowe i automatyczne podsumowanie

Strona 1:

Jak wiemy, protokół RIP to klasowy protokół routingu, który automatycznie podsumowuje sieci klasowe na granicach większych sieci. Na ilustracji widzimy, że router R2 ma interfejsy w więcej niż jednej dużej sieci klasowej. Z tego powodu dla protokołu RIP R2 jest routerem brzegowym (ang. boundary router). Interfejsy Serial 0/0/0 i FastEthernet 0/0 routera R2 znajdują się w sieci 172.30.0.0. Interfejs Serial 0/0/1 w sieci 192.168.4.0.

Ponieważ routery brzegowe podsumowują podsieci RIP na granicach dużych sieci, przy wysyłaniu aktualizacji z interfejsu Serial 0/0/1 routera R2 aktualizacje dla sieci 172.30.1.0, 172.30.2.0 i 172.30.3.0 zostaną automatycznie podsumowane do 172.30.0.0.

W dwóch kolejnych podrozdziałach wyjaśniono, w jaki sposób routery brzegowe wykonują to podsumowanie.

5.4.3 Przetwarzanie aktualizacji RIP

Strona 1:

Reguły przetwarzania aktualizacji RIPv1

Aktualizacjami RIPv1 zarządzają dwie poniższe reguły:

• Jeśli aktualizacja routingu i interfejs, na którym została odebrana, należą do tej samej dużej sieci, stosowana jest maska podsieci interfejsu.

• Jeśli aktualizacja routingu i interfejs, na którym została odebrana, należą do różnych dużych sieci, stosowana jest domyślna maska podsieci dla klasy tej sieci.

Przykład przetwarzania aktualizacji RIPv1

Na ilustracji routing R2 odbiera aktualizację od routera R1 i wprowadza sieć do tablicy routingu. Skąd router R2 wie, że ta podsieć ma maskę podsieci /24 (255.255.255.0)? Wie to, ponieważ:

• R2 odebrał tę informację na interfejsie, który należy do tej samej sieci klasowej (172.30.0.0) co wchodząca aktualizacja 172.30.1.0.

• Adres IP, dla którego router R2 odebrał komunikat 172.30.1.0 in 1 hops, był na interfejsie Serial 0/0/0 z adresem IP 172.30.2.2 i maską podsieci 255.255.255.0 (/24).

• Router R2 stosuje maskę podsieci tego interfejsu do tej i pozostałych podsieci 172.30.0.0, które odbiera na tym interfejsie - w tym przypadku 172.30.1.0.

• W tablicy routingu została umieszczona podsieć 172.30.1.0/24.

Routery z protokołem RIPv1 są ograniczone do używania tej samej maski podsieci dla wszystkich podsieci z tą samą siecią klasową.

Jak opisano w kolejnych rozdziałach, bezklasowe protokoły routingu, na przykład RIPv2, pozwalają tej samej dużej (klasowej) sieci używać różnych masek podsieci w różnych podsieciach, co nazywa się maskami podsieci o zmiennej długości (VLSM).

5.4.4 Wysyłanie aktualizacji RIP

Strona 1:

Obserwacja automatycznego podsumowania za pomocą polecenia debug

Brzegowy router R2, wysyłając aktualizację, umieszcza w niej adres sieciowy i skojarzoną z nim metrykę. Jeśli wpis trasy jest dla aktualizacji wysyłanej z innej dużej sieci, adres sieciowy we wpisie trasy zostaje zsumowany do dużego, czyli klasowego, adresu sieciowego. I właśnie to router R2 robi z adresami 192.168.4.0 i 192.168.5.0. Wysyła te sieci klasowe do routera R1.

Router R2 ma również trasy do podsieci 172.30.1.0/24, 172.30.2.0/24 i 172.30.3.0/24. W aktualizacji routingu do routera R3 na interfejsie Serial 0/0/1 R2 wysyła jedynie podsumowanie klasowego adresu sieciowego 172.30.0.0.

Jeśli wpis trasy jest przeznaczony dla aktualizacji wysyłanej w obrębie dużej sieci, do ustalenia ogłaszanego adresu sieciowego stosowana jest maska podsieci interfejsu wyjściowego. Router R2, wysyłając do routera R1 informacje o podsieci 172.30.3.0, ustala adres za pomocą maski podsieci interfejsu Serial 0/0/0.

Router R1 odbiera aktualizację 172.30.3.0 na interfejsie Serial 0/0/0, który ma adres 172.30.2.1/24. Ponieważ zarówno aktualizacja routingu, jak i interfejs należą do tej samej dużej sieci, router R1 do trasy 172.30.3.0 stosuje maskę tego interfejsu, czyli /24.

Kliknij tablicę routingu R1 oraz R3 na ilustracji, aby je porównać

Jak widać, router R1 ma trzy trasy do klasowej sieci 172.30.0.0, która została podzielona za pomocą maski /24, czyli 255.255.255.0. Router R3 ma tylko jedną trasę do sieci 172.30.0.0 i nie została ona podzielona na podsieci. R3 ma w swojej tablicy routingu dużą sieć. Jednak błędne byłoby założenie, że router R3 nie ma pełnej łączności. R3 będzie wysyłać wszystkie pakiety przeznaczone do 172.30.1.0/24, 172.30.2.0/24 i 172.30.3.0/24 do routera R2, ponieważ każda z tych trzech sieci należy do 172.30.0.0/16 i jest osiągalna przez router R2.

5.4.5 Zalety i wady automatycznego podsumowania

Strona 1:

Zalety automatycznego podsumowania

Jak widać ilustacji, protokół RIP na routerze R2 automatycznie podsumowuje aktualizacje pomiędzy sieciami klasowymi. Ponieważ aktualizacja 172.30.0.0 jest wysyłana z

interfejsu (Serial 0/0/1) znajdującego się w innej sieci klasowej (192.168.4.0), protokół RIP zamiast aktualizacji dla każdej z różnych podsieci wysyła pojedynczą aktualizację dla

całej sieci klasowej. Proces ten przypomina podsumowanie kilku tras statycznych w jedną trasę statyczną. Dlaczego podsumowanie automatyczne jest zaletą?

• Wysyłane i odbierane są mniejsze aktualizacje routingu, więc potrzeba mniej szerokości pasma na wymianę aktualizacji pomiędzy routerami R2 i R3.

• Router R3 ma jedną trasę do sieci 172.30.0.0/16, niezależnie od tego, ile jest w niej podsieci czy też w jaki sposób została podzielona. Używanie jednej trasy daje w efekcie szybszy proces wyszukiwania w tablicy routingu routera R3.

Strona 2:

Czy automatyczne podsumowanie ma jakieś wady? Tak, jeśli w topologii skonfigurowane są sieci nieciągłe.

Wady automatycznego podsumowania

Jak widzimy na ilustracji, zmienił się schemat adresowania. Użyjemy tej topologii do pokazania głównej wady klasowych protokołów routingu takich jak RIPv1 - braku obsługi sieci nieciągłych.

Klasowe protokoły routingu w aktualizacjach routingu nie umieszczają maski podsieci. Sieci są automatycznie podsumowywane na granicach dużych sieci, ponieważ router odbierający nie potrafi ustalić maski trasy. Dzieje się tak dlatego, że interfejs odbierający może mieć inną maskę niż trasy podzielone na podsieci.

Zwróćmy uwagę, że zarówno R1, jak i R3 mają podsieci z dużej sieci 172.30.0.0/16, natomiast router R2 nie ma. W gruncie rzeczy routery R1 i R3 są dla 172.30.0.0/16 routerami brzegowymi, ponieważ są oddzielone inną siecią główną 209.165.200.0/24. W ten sposób powstaje sieć nieciągła (ang. discontiguous network), ponieważ dwie podsieci 172.30.0.0/24 są oddzielone przynajmniej jedną dużą siecią. 172.30.0.0/16 to sieć nieciągła.

Strona 3:

W topologiach nieciągłych z protokołem RIPv1 nie ma zbieżności

Na ilustracji widzimy konfigurację protokołu RIP dla każdego routera z topologii. Protokół RIPv1 jest skonfigurowany prawidłowo, ale nie może ustalić wszystkich sieci w tej nieciągłej topologii. Aby odpowiedzieć na pytanie, dlaczego tak się dzieje, przypomnijmy sobie, że router ogłasza klasowe adresy sieciowe tylko z tych interfejsów, które nie należą do ogłaszanej trasy. W efekcie router R1 nie będzie ogłaszał sieci 172.30.1.0 ani 172.30.2.0 routerowi R2 przez sieć 209.165.200.0. R3 nie będzie ogłaszał sieci 172.30.100.0 ani 172.30.200.0 routerowi R2 przez sieć 209.165.200.0. Oba routery będą jednak ogłaszały klasowy adres sieciowy 172.30.0.0, trasę sumaryczną do routera R3.

Jaki jest efekt? Nie dołączając maski podsieci do aktualizacji routingu, RIPv1 nie może ogłaszać informacji o konkretnych trasach, które pozwalałaby routerom prawidłowo wysyłać pakiety do podsieci 172.30.0.0/24.

Kliknij przyciski show ip route dla R1, R2 i R3 na ilustracji, aby przeglądać tablicę routingu.

• Router R1 nie ma tras do sieci LAN przyłączonych do routera R3.

• Router R3 nie ma tras do sieci LAN przyłączonych do routera R1.

• Router R2 ma dwie równorzędne trasy do sieci 172.30.0.0.

• Router R2 rozłoży każdy ruch skierowany do podsieci sieci 172.30.0.0. Oznacza to, że połowę ruchu otrzyma router R1, a połowę router R3 niezależnie od tego, czy celem tego ruchu jest jedna z połączonych z nimi sieci LAN.

W rozdziale 7 pokazano inną wersję tej topologii. Ilustruje ona różnicę pomiędzy routingiem klasowym i bezklasowym.

5.5 Trasa domyślna a protokół RIPv1

5.5.1 Zmodyfikowana topologia: scenariusz C

Strona 1:

Dodawanie do topologii dostępu do Internetu

RIP był pierwszym protokołem routingu dynamicznego powszechnie stosowanym we wczesnych implementacjach pomiędzy klientami a dostawcami Internetu (ISP), jak również pomiędzy różnymi ISP. Ale w dzisiejszych sieciach klienci nie muszą już wymieniać aktualizacji routingu ze swoimi ISP. Routery klientów łączące się z ISP nie potrzebują spisów wszystkich tras w Internecie. Routery te mają za to trasę domyślną, którą wysyłany jest cały ruch do routera ISP, kiedy router klienta nie ma trasy do celu. ISP konfiguruje trasę statyczną wskazującą na router klienta dla adresów znajdujących się w sieci klienta.

W scenariuszu C router R3 jest usługodawcą z dostępem do Internetu, który jest symbolizowany przez chmurę. Routery R3 i R2 nie wymieniają aktualizacji RIP. Zamiast tego router R2 używa trasy domyślnej prowadzącej do sieci LAN routera R3 i wszystkich innych celów, których nie ma w tablicy routingu. Dla ruchu do podsieci 172.30.1.0, 172.30.2.0 i 172.30.3.0 router R3 używa sumarycznej trasy statycznej.

W tej topologii nie trzeba zmieniać adresowania. Jest takie samo jak w scenariuszu B. Należy jednak wykonać poniższe kroki:

Kliknij konfigurację RIP na ilustracji.

1. Wyłącz routing RIP dla sieci 192.168.4.0

2. Na routerze R2 skonfiguruj statyczną trasę domyślną, aby wysyłać ruch do routera R3.

3. Wyłącz routing RIP na routerze R3

4. Na routerze R3 skonfiguruj trasę statyczną do podsieci 172.30.0.0.

Kliknij zakładkę show ip route na ilustracji, aby zobaczyć wyniki.

5.5.2 Propagowanie trasy domyślnej w protokole RIPv1

Strona 1:

Aby zapewnić łączność z Internetem wszystkim pozostałym sieciom w domenie routingu RIP, domyślna trasa statyczna musi zostać ogłoszona wszystkim pozostałym routerom używającym protokołu routingu dynamicznego. Na routerze R1 można skonfigurować domyślną trasę statyczną do routera R2, ale ta technika nie jest skalowalna. Dla każdego routera dodawanego do domeny routingu RIP należałoby wówczas konfigurować kolejną domyślną trasę statyczną. Dlaczego nie miałby tego za nas zrobić protokół routingu?

W wielu protokołach routingu, w tym RIP, można użyć w trybie konfiguracji routera polecenia default-information originate, aby router w swoich aktualizacjach RIP wysyłał informację o domyślnej trasie statycznej. Na ilustracji, na routerze R2 skonfigurowano polecenie default-information originate. W wynikach polecenia debug ip rip widzimy teraz, że do routera R1 wysyłana jest domyślna statyczna trasa „zerowa”.

Kliknijshow ip route na ilustracji.

W tablicy routingu routera R1 widzimy kandydatkę na trasę domyślną oznaczoną kodem R*. Domyślna trasa statyczna na routerze R2 jest ogłaszana routerowi R1 w aktualizacji RIP. Router R1 ma łączność z siecią LAN za pośrednictwem routera R3 i z każdym celem w Internecie.

5.6 Konfiguracja RIPv1 Laboratoria

5.6.1 Podstawowa konfiguracja protokołu RIP

Strona 1:

W tym ćwiczeniu używamy omówionych w tym rozdziale poleceń konfiguracyjnych i diagnostycznych z wykorzystaniem trzech wprowadzonych scenariuszy. Należy skonfigurować routing RIP, zweryfikować konfigurację, zbadać problem z sieciami nieciągłymi, poobserwować automatyczne podsumowanie, a następnie skonfigurować i rozpropagować trasę domyślną.

Kliknij ikonę, aby uzyskać więcej szczegółów.

5.7 Podsumowanie

5.7.1 Podsumowanie i powtórzenie

Strona 1:

Podsumowanie

RIPv1 to klasowy protokół routingu wektora odległości. RIPv1 był jednym z pierwszych protokołów routingu opracowanych dla pakietów IP. Metryką protokołu RIP jest liczba skoków, a metryka o wartości 16 skoków oznacza, że trasa jest nieosiągalna. W efekcie protokołu RIP można używać tylko w takich sieciach, w których pomiędzy dwiema dowolnymi sieciami znajduje się maksymalnie 15 routerów.

Komunikaty RIP są enkapsulowane w segmencie pakietu UDP, a port źródłowy i docelowy to 520. Routery RIP wysyłają do swoich sąsiadów co 30 sekund pełne tablice routingu oprócz informacji o tych trasach, które są objęte regułą podzielonego horyzontu.

Protokół RIP włączamy, wpisując w trybie konfiguracji globalnej polecenie router rip. Wydając polecenie network, określamy, które interfejsy routera będą miały włączony protokół RIP oraz klasowe adresy sieciowe każdej sieci połączonej bezpośrednio. Polecenie network włącza na interfejsie wysyłanie i odbieranie aktualizacji RIP oraz ogłaszanie tej sieci innym routerom w aktualizacjach RIP.

Polecenia debug ip rip możemy użyć do przeglądania wysyłanych i odbieranych przez router aktualizacji RIP. Aby zapobiec wysyłaniu aktualizacji RIP z danego interfejsu, na przykład do sieci lokalnej, w której nie ma innych routerów, używamy polecenia passive-interface.

Wpisy RIP są wyświetlane w tablicy routingu z kodem R i mają odległość administracyjną 120. Trasy domyślne są ogłaszane przez protokół RIP po skonfigurowaniu domyślnej trasy statycznej i wydaniu polecenia default-information originate.

Protokół RIPv1, wysyłając aktualizację z interfejsu, który znajduje się w innej sieci głównej niż adres trasy do podsieci, automatycznie podsumowuje podsieci do adresu klasowego. Ponieważ RIPv1 to klasowy protokół routingu, maska podsieci nie jest dołączana do aktualizacji routingu. Kiedy router odbiera aktualizację routingu RIPv1, musi ustalić maskę podsieci takiej trasy. Jeśli trasa należy do tej samej sieci głównej co aktualizacja, RIPv1 stosuje maskę podsieci interfejsu odbierającego. Jeśli trasa należy do innej sieci klasowej niż interfejs odbierający, RIPv1 stosuje domyślną maskę klasową.

Polecenia show ip protocols możemy użyć, aby wyświetlić informacje dla każdego protokołu routingu używanego na routerze. Jeśli chodzi o RIP, polecenie to wyświetla informacje o licznikach, stan automatycznego podsumowania, sieci RIP włączone dla tego routera oraz inne informacje.

Ponieważ RIPv1 to klasowy protokół routingu, nie obsługuje ani sieci nieciągłych, ani VLSM. Oba te zagadnienia omówiono w rozdziale 7.

Strona 4:

Aby nauczyć się więcej

RFC (Request For Comments) to seria dokumentów wysyłanych do IETF (Internet Engineering Task Force) w celu zaproponowania internetowego standardu albo przekazania nowych koncepcji, informacji, a czasami także żartów. W dokumencie RFC 1058 napisanym przez Charlesa Hedricka zdefiniowano protokół RIP.

Dokumenty RFC można znaleźć na kilku serwisach internetowych, w tym www.ietf.org. Warto przeczytać całość albo chociaż fragmenty dokumentu RFC 1058. Większość zawartych w nim informacji została przedstawiona w tym rozdziale.

9

---