Dół formularza

CCNA Exploration - Protokoły i koncepcje routingu

7 Protokół RIPv2

7.0 Wprowadzenie do rozdziału

7.0.1 Wprowadzenie do rozdziału

Strona 1:

Druga wersja protokołu RIP (RIPv2) została zdefiniowana w dokumencie RFC 1723. RIPv2 to pierwszy bezklasowy protokół routingu omówiony w tej książce. Ilustracja przedstawia protokół RIPv2 w odpowiedniej perspektywie wobec innych protokołów routingu. Mimo że nadaje się do wykorzystania w pewnych środowiskach, traci popularność na rzecz innych protokołów routingu, takich jak EIGRP, OSPF i IS-IS, które mają większe możliwości i są lepiej skalowalne.

Mimo to w pewnych sytuacjach obie wersje protokołu RIP są nadal używane. Choć protokół RIP nie ma wielu funkcji zaimplementowanych w późniejszych protokołach, jego prostota i powszechne używanie w wielu systemach operacyjnych sprawiają, że idealnie nadaje się do mniejszych, jednorodnych sieci, gdzie wymagana jest obsługa urządzeń od wielu producentów, zwłaszcza w środowiskach uniksowych.

Nawet jeśli nie mamy zamiaru używać protokołu RIPv2, idealnie nadaje się on do wy jaśnienia różnic pomiędzy klasowym protokołem routingu (RIPv1) a bezklasowym protokołem routingu (RIPv2). Główne ograniczenie RIPv1 stanowi to, że jest klasowym protokołem routingu. Jak wiemy, klasowe protokoły routingu w wysyłanych aktualizacjach routingu nie dołączają do adresu sieciowego maski podsieci. Może to być przyczyną problemów w sieciach nieciągłych albo takich, w których używa się VLSM. Ponieważ RIPv2 to bez kla-sowy protokół routingu, maski podsieci są dołączane do aktualizacji routingu, dzięki czemu RIPv2 jest bardziej kompatybilny z nowoczesnymi środowiskami routingu.

RIPv2 w gruncie rzeczy nie jest nowym protokołem, a jedynie udoskonaleniem i rozszerzeniem funkcji protokołu RIPv1. Wśród tych ulepszeń warto wymienić:

• wysyłanie w aktualizacjach routingu adresów następnego skoku,

• wysyłanie aktualizacji przy użyciu adresów grupowych,

• dostępność opcji uwierzytelniania.

Tak jak RIPv1, RIPv2 to protokół routingu wektora odległości. Obie wersje protokołu RIP mają wymienione niżej wspólne cechy i ograniczenia.

• Używanie licznika wstrzymania i innych liczników mających za zadanie zapobiegać tworzeniu się pętli routingu.

• Używanie podzielonego horyzontu i podzielonego horyzontu z zatruciem wstecz, również po to, aby wyeliminować powstawanie pętli routingu.

• Używanie aktualizacji wyzwalanych w odpowiedzi na zmiany w topologii w celu szybszego osiągania stanu zbieżności.

• Maksymalna wartość liczby skoków to 15. 16 oznacza sieć nieosiągalną.

7.1 Ograniczenia protokołu RIPv1

7.1.1 Topologia laboratoryjna

Strona 1:

Na rysunku przedstawiono używaną w tym rozdziale topologię. Scenariusz ten jest podobny do domeny routingu z trzema routerami, która pojawiła się pod koniec rozdziału 5 „Protokół RIPv1”. Jak pamiętamy, zarówno za routerem R1, jak i za routerem R3 znajdują się podsieci, które są częścią dużej klasowej sieci 172.30.0.0/16 (klasa B). Wiemy również, że routery R1 i R3 są połączone z routerem R3 przez podsieci dużej klasowej sieci 209.165.200.0/24 (klasa C). Topologia to przykład sieci nieciągłej (ang. discontiguous network). W tym przypadku 172.30.0.0/16 jest przedzielona sieciami 209.165.200.228/30 i 209.165.200.232/30.

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

Trasa sumaryczna

Widzimy, że router R2 ma statyczną trasę sumaryczną do sieci 192.168.0.0/16. Konfiguracja trasy statycznej będzie przedstawiona później.

Koncepcja i konfiguracja statycznych tras sumarycznych są omówione w rozdziale 2 „Routing statyczny”. Informacje o trasie statycznej można umieszczać w aktualizacjach protokołu routingu. Nazywane jest to redystrybucją (ang. redistribution) i zostało omówione w dalszej części tego rozdziału. W tej chwili wystarczy wiedzieć, że ta trasa sumaryczna będzie problemem dla protokołu RIPv1, ponieważ 192.168.0.0/16 nie jest adresem dużej sieci klasowej i zawiera wszystkie wersje /24, co widzimy na topologii.

Zarówno R1, jak i R3 posiadają sieci VLSM i dzielą przestrzeń adresową z głównej sieci klasowej 172.30.0.0/16. Następnie przyglądniemy się schematowi adresacji VLSM.

Strona 2:

VLSM

Zapoznaj się ze schematem adresacji VLSM na ilustracji. W topologii na rysunku widzimy, że routery R1 i R3 mają połączone sieci VLSM. Zarówno R1, jak i R3 mają skonfigurowane podsieci /24 sieci 172.30.0.0/16. Cztery z tych podsieci /24 zostały przypisane: dwie do R1 (172.30.1.0/24 i 172.30.2.0/24), a dwie do R3 (172.30.100.0/24 i 172.30.110.0/24).

Na routerze R3 adres 172.30.200.0/24 został ponownie podzielony na podsieci z wykorzystaniem czterech pierwszych bitów na podsieci, a czterech ostatnich na hosty. Daje nam to maskę 255.255.255.240, czyli /28. Podsieć 1 oraz Podsieć 2 są przydzielone do routera R3. Oznacza to, że podsieć 172.30.200.0/24 nie może być już używana nawet, gdy pozostałe podsieci /28 mogą.

Strona 3:

Adresy prywatne RFC 1918

Dokument RFC 1918 i teoretyczne założenia adresowania prywatnego zostały już omówione. We wszystkich przykładach adresowania wewnętrznego na kursie używane są adresy prywatne.

W tabeli zebrano adresy zgodne z RFC 1918. Kiedy ruch IP jest przesyłany przez łącza WAN za pośrednictwem dostawcy ISP albo, gdy użytkownicy wewnętrzni muszą mieć dostęp do zewnętrznych stanowisk, koniecznym jest używanie publicznego adresu IP.

Przykładowe adresy IP Cisco

Zwróćmy uwagę, że łącza WAN pomiędzy routerami R1, R2 i R3 używają publicznych adresów IP. Mimo że te adresy IP nie są adresami prywatnymi zgodnymi z RFC 1918, firma Cisco nabyła trochę publicznej przestrzeni adresowej do wykorzystania w przykładach.

Adresy przedstawione na ilustracji są prawidłowymi, publicznymi adresami IP które są routowalne w Internecie. Cisco wykorzystuje te adresy wyłącznie w celach edukacyjnych. Dlatego, ten kurs i przyszłe kursy będą używać tych adresów, kiedy będzie potrzeba użycia adresów publicznych.

Na ilustracji, R1, R2 oraz R3 są podłączone z użyciem publicznej przestrzeni adresowej Cisco 209.165.200.224/27. Ponieważ łącza WAN potrzebują jedynie dwóch adresów, sieć 209.165.200.224/27 jest podzielona z maską /30. W topologii, podsieć 1 jest przypisana do łącza WAN pomiędzy R1 i R2. Podsieć 2 jest przypisana do łącza WAN pomiędzy R2 i R3.

Strona 4:

Interfejsy pętli zwrotnej

Zwróćmy uwagę, że router R3 używa interfejsów pętli zwrotnej (Lo0, Lo1 i Lo2). Interfejs pętli zwrotnej (ang. loopback interface) to interfejs tylko programowy, używany jako emulator interfejsu. Można do niego przypisać adres IP. Interfejsy pętli zwrotnej mają poza tym specjalne zadania przy protokołach routingu takich jak OSPF. Omówiono je w dalszej części tego rozdziału.

W środowisku laboratoryjnym interfejsy pętli zwrotnej są przydatne przy tworzeniu dodatkowych sieci bez potrzeby dodawania nowych interfejsów fizycznych do routera.

Interfejs pętli zwrotnej mogą być pingowane i podsieć może być rozgłaszana w aktualizacjach protokołu routingu. Dlatego też interfejsy pętli zwrotnej idealnie nadają się do

tworzenia symulacji wielu sieci podłączonych do tego samego routera. W naszym przykładzie do omówienia wielu podsieci i VLSM nie potrzeba czterech interfejsów na routerze R3. Wystarczy wykorzystać interfejsy pętli zwrotnej.

7.1.2 Ograniczenia topologii RIPv1

Strona 1:

Trasy statyczne i interfejsy zerowe

Do skonfigurowania trasy supersieci została użyta następująca komenda:

R2(config)#ip route 192.168.0.0 255.255.0.0 Null0

Jak pamiętamy, CIDR umożliwia agregację tras. Oznacza to, że do reprezentowania wielu tras niższego poziomu można użyć jednej trasy wysokopoziomowej z maską podsieci mniejszą od maski klasowej. Efektem jest mniej wpisów w tablicy routingu. Trasa statyczna na routerze R2 do podsumowania wszystkich 256 sieci od 192.168.0.0/24 do 192.168.255.0/24 używa maski /16.

Ta przestrzeń adresowa reprezentowana przez sumaryczną trasę statyczną 192.168.0.0/16 w rzeczywistości nie istnieje. Aby utworzyć symulację tej trasy statycznej, jako interfejsu wyjściowego użyjemy interfejsu zerowego (ang. null interface). Nie trzeba wydawać poleceń, aby utworzyć lub skonfigurować interfejs zerowy. Jest on zawsze włączony, ale ani nie wysyła, ani nie odbiera ruchu. Ruch wysyłany do interfejsu zerowego jest odrzucany. W tym przykładzie interfejs zerowy będzie pełnił rolę interfejsu wyjściowego dla trasy statycznej. Wiemy z rozdziału 2, że zanim trasa statyczna zostanie zainstalowana w tablicy routingu, musi mieć aktywny interfejs wyjściowy. Użycie interfejsu zerowego pozwala routerowi R2 ogłaszać w procesie RIP trasę statyczną, mimo że sieci należące do sumarycznej trasy 192.168.0.0/16 w rzeczywistości nie istnieją.

Redystrybucja tras

Drugim poleceniem wymagającym wyjaśnienia jest redistribute static:

R2(config-router)#redistribute static

Redystrybucja polega na pobraniu tras z jednego źródła routingu i wysłania ich do innych źródeł routingu. W naszej przykładowej topologii chcemy, aby proces RIPv1 na routerze R2 redystrybuował naszą trasę statyczną (192.168.0.0/16), importując trasę do RIPv1, a następnie wysyłając ją do routerów R1 i R3 za pomocą procesu RIPv1. Przekonamy się, czy tak się faktycznie dzieje, a jeśli nie, to dlaczego.

Strona 2:

Sprawdzanie i testowanie łączności

Aby dowiedzieć się, czy topologia ma pełną łączność, najpierw sprawdzamy, czy oba łącza szeregowe routera R2 są włączone, wydając polecenie show ip interface brief. Na ilustracji widzimy wyniki tego polecenia wydanego na routerze R2. Jeśli łącze jest wyłączone, w wynikach polecenia w kolumnie Status lub Protocol (albo w obu) zobaczymy down. Jeśli łącze działa, w obu polach, tak jak w naszym przypadku, zobaczymy up. Router R2 ma bezpośrednią łączność z routerami R1 i R3 przez łącza szeregowe.

Ale czy z routera R2 można użyć polecenia ping dla sieci lokalnych za routerami R1 i R3? Czy występują problemy z łącznością z klasowym protokołem routingu i nieciągłych podsieci 172.30.0.0? Komunikację pomiędzy routerami testujemy, używając polecenia ping.

Kliknij Pingowanie R2 na ilustracji.

Widzimy, jak router R2 próbuje użyć polecenia ping dla interfejsu 172.30.1.1 na routerze R1 i interfejsu 172.30.100.1 na routerze R3. Za każdym razem, gdy R2 wysyła sygnał ping do jednej z podsieci 172.30.0.0 na routerze R1 lub R3, jedynie około 50 procent komunikatów ICMP kończy się powodzeniem.

Kliknij Pingowanie R1 na ilustracji.

Widzimy, że router R1 może użyć polecenia ping dla adresu 10.1.0.1, ale nie udaje mu się użyć polecenia ping dla interfejsu 172.30.100.1 na routerze R3.

Kliknij Pingowanie R3 na ilustracji.

Widzimy, że R3 ma odpowiedź polecenia ping dla 10.1.0.1, ale nie udaje mu się otrzymać odpowiedzi ping dla interfejsu 172.30.1.1 na routerze R1.

Jak widać, kiedy staramy się nawiązać komunikację z nieciągłymi podsieciami 172.30.0.0, pojawia się problem. W kolejnych podrozdziałach zbadamy tablice routingu i aktualizacje routingu, aby z bliska przyjrzeć się temu problemowi i spróbować go rozwiązać.

7.1.3 Protokół RIPv1: sieci nieciągłe

Strona 1:

Jak już dobrze wiemy, RIPv1 to klasowy protokół routingu. Jak widzisz, nie dołącza do aktualizacji routingu masek podsieci, o czym przekonuje nas format komunikatu RIPv1. Dlatego też protokół RIPv1 nie może obsługiwać sieci nieciągłych, VLSM i supersieci CIDR. Czy jest jednak możliwość rozszerzenia formatu komunikatu RIPv1, aby zmieściła się maska podsieci, co pozwoliłoby na skonfigurowanie sieci nieciągłej? Jak należałoby zmienić przedstawiony na rysunku format komunikatu, aby zawierał maskę podsieci?

Strona 2:

Ponieważ aktualizacja nie zawiera maski podsieci, RIPv1 i inne klasowe protokoły routingu muszą sumaryzować sieci na granicach dużych sieci. Jak widzimy na ilustracji, proces RIPv1 na routerach R1 i R3, wysyłając aktualizacje routingu do routera R2, podsumuje ich podsieci 172.30.0.0 do adresu dużej sieci klasowej 172.30.0.0. Z perspektywy routera R2, obie aktualizacje posiadają równy koszt jednego skoku, aby osiągnąć sieć 172.30.0.0/16. Jak zobaczysz, R2 instaluje obie trasy w tablicy routingu.

Strona 3:

Badanie tablic routingu

Jak się przekonaliśmy, router R2 próbuje użyć polecenia ping dla adresu w jednej z podsieci 172.30.0.0 z różnym skutkiem.

Kliknij Trasy R2 na ilustracji.

Widzimy, że router R2 ma dwie równorzędne trasy do sieci 172.30.0.0/16. Powodem jest to, że zarówno R1, jak i R3 wysyłają do R2 aktualizację RIPv1 dla sieci 172.30.0.0 z metryką jednego skoku. Ponieważ R1 i R3 automatycznie podsumowały poszczególne podsieci, tablica routingu routera R2 zawiera tylko klasowy adres sieciowy 172.30.0.0 i dodaje maskę podsieci klasy B /16.

Wydając polecenie debug ip rip, możemy zbadać zawartość aktualizacji routingu w czasie, gdy są wysyłane i odbierane.

Kliknij Debugowanie 1 R2 na ilustracji.

Zauważmy, że router R2 otrzymuje dwie równorzędne trasy do sieci 172.30.0.0 z metryką jednego skoku. Pierwszą trasę na interfejsie Serial 0/0/0 routera R1, a drugą na interfejsie S0/0/1 routera R3. Poza tym w aktualizacji do adresu sieciowego nie dołączono maski podsieci.

A co z routerami R1 i R3? Czy one też otrzymują informacje o swoich podsieciach 172.30.0.0?

Kliknij Trasy R1 na ilustracji.

Widzimy, że router R1 ma własne trasy 172.30.0.0: 172.30.2.0/24 i 172.30.1.0/24. Ale R1 nie wysyła do R2 informacji o tych podsieciach. Router R3 ma podobną tablicę routingu. Zarówno R1, jak i R3 to routery brzegowe i w swoich aktualizacjach RIPv1 wysyłają do routera R2 tylko sumaryczną sieć 172.30.0.0. W efekcie router R2 wie tylko o klasowej sieci 172.30.0.0/16 i nie wie o istnieniu jakiejkolwiek podsieci 172.30.0.0.

Kliknij Debugowanie 2 R2 na ilustracji.

Wróćmy do wyniku polecenia debug ip rip. Widzimy, że router R2 w swoich aktualizacjach wysyłanych do R1 i R3 nie umieszcza sieci 172.30.0.0. Dlaczego? Ponieważ działa tutaj reguła podzielonego horyzontu. R2 dowiedział się o sieci 172.30.0.0 na dwóch interfejsach, S0/0/0 i S0/0/1. A ponieważ R2 dowiedział się o sieci 172.30.0.0 na tych interfejsach, nie będzie wysyłał informacji o tej sieci w aktualizacjach wysyłanych z tych interfejsów.

7.1.4 Protokół RIPv1: brak obsługi VLSM

Strona 1:

Ponieważ protokół RIPv1 nie wysyła w aktualizacjach routingu maski podsieci, nie może obsługiwać VLSM. Na routerze R3 skonfigurowano następujące podsieci VLSM (każda z nich należy do sieci klasy B 172.30.0.0/16):

• 172.30.100.0/24 (FastEthernet 0/0)

• 172.30.110.0/24 (Loopback 0)

• 172.30.200.16/28 (Loopback 1)

• 172.30.200.32/28 (Loopback 2)

Jak widać w przykładzie aktualizacji 172.30.0.0/16 wysyłanych do routera R2 przez routery R1 i R3, RIPv1 podsumowuje podsieci do granicy klasy albo używa maski podsieci interfejsu wyjściowego, aby ustalić, które podsieci ogłaszać.

Kliknij przycisk Topologia na ilustracji.

Aby pokazać, w jaki sposób RIPv1 używa maski podsieci interfejsu wyjściowego, na moment wprowadzimy do topologii router R4, który zostanie połączony z routerem R3 przez interfejs Fa0/0 w sieci 172.30.100.0/24.

Kliknij Komunikaty routera na ilustracji.

W odniesieniu do wyników polecenia debug ip rip na ilustracji. Na routerze R3 widzimy, że jedyną podsiecią 172.30.0.0 dołączaną w aktualizacjach RIPv1 wysyłanych z interfejsu Fa0/0 do routera R4 jest 172.30.110.0.

Dlaczego proces RIPv1 na routerze R3 w aktualizacjach wysyłanych do routera R4 nie zamieszcza informacji o pozostałych podsieciach - 172.30.200.16/28 i 172.30.200.32/28? Podsieci te nie posiadają takiej samej maski podsieci jak FastEthernet 0/0. Właśnie dlatego wszystkie podsieci muszą używać tej samej maski podsieci, kiedy w sieci zaimplementowany jest klasowy protokół routingu.

Bardziej szczegółowe wyjaśnienie

R3 potrzebuje określić, które podsieci 172.30.0.0 zamieścić w aktualizacjach opuszczających interfejs FastEthernet 0/0 z adresem IP 172.30.100.1/24. Zamieszcza jedynie te trasy do podsieci sieci 172.30.0.0 ze swojej tablicy routingu, które mają maskę taką jak interfejs wyjściowy. Jeśli interfejs ma adres 172.30.100.1 z maską /24, to będzie zawierać jedynie podsieci 172.30.0.0 z maską /24. Jedyna, która spełnia warunek to 172.30.110.0.

Pozostałe podsieci 172.30.0.0, 172.30.200.16/28 oraz 172.30.200.32/28 nie są zawarte, ponieważ maski /28 nie pasują do maski /24 interfejsu wyjściowego. Router odbierający R4 może jedynie zastosować swoja maskę interfejsu /24 do ogłaszania podsieci 172.30.0.0 poprzez RIPv1. R4 może zastosować złą maskę /24 do tych podsieci z maską /28.

7.1.5 Protokół RIPv1: brak obsługi CIDR

Strona 1:

Trasa statyczna 192.168.0.0/16

Przedstawione dotąd informacje są nam już znane w pewnym stopniu z rozdziału 5. Jest jednak jeszcze jeden problem, którym się nie zajmowaliśmy.

Kliknij Routing R2 na ilustracji.

Widzimy konfigurację trasy statycznej do sieci 192.168.0.0/16 na routerze R2 oraz polecenie redistribute static nakazujące protokołowi RIP umieszczać w aktualizacjach informacje o tej trasie. Ta trasa statyczna to podsumowanie podsieci 192.168.0.0/24 z przedziału od 192.168.0.0/24 do 192.168.255.0/24.

R2(config)#ip route 192.168.0.0 255.255.0.0 Null0

Kliknij Trasy R2 na ilustracji.

Widzimy, że omawiana trasa statyczna znajduje się w tablicy routingu routera R2.

Kliknij Trasy R1 na ilustracji.

Czytając tablicę routingu routera R1 zauważamy, że router ten nie odbiera tej trasy 192.168.0.0/16 w aktualizacjach RIP od routera R2 mimo, że można by tego oczekiwać.

Kliknij Debugowanie R2 na ilustracji.

Gdy wydamy polecenie debug ip rip na serwerze R2, zauważymy, że w aktualizacjach wysyłanych do routerów R1 i R3 trasa 192.168.0.0/16 nie jest dołączana. Co jest tego przyczyną? Przyjrzyjmy się trasie 192.168.0.0/16. Jaka jest klasa tej trasy? Klasa A, B czy C? Jaka jest maska używana w trasie statycznej? Czy zgadza się z klasą? Czy maska w trasie statycznej jest mniejsza od maski klasy?

Trasę statyczną 192.168.0.0 skonfigurowaliśmy z maską /16. Jest ona krótsza od maski /24 klasy C Ponieważ maska nie jest zgodna z klasą ani z podsiecią klasy, RIPv1 nie włączy tej trasy do swoich aktualizacji wysyłanych do innych routerów.

RIPv1 i inne klasowe protokoły routingu nie obsługują tras CIDR, które są trasami zsumowanymi za pomocą maski podsieci krótszej niż klasowa maska trasy. RIPv1 ignoruje te supersieci w tablicy routingu i nie zamieszcza ich w aktualizacjach wysyłanych do innych routerów. Powodem jest to, że router odbierający potrafi zastosować do aktualizacji jedynie dłuższą maskę sieciową - krótszej maski /16 nie potrafi.

Uwaga: Gdyby statyczną trasę 192.168.0.0 skonfigurować z maską /24 lub większą, trasa ta byłaby uwzględniana w aktualizacjach RIP. Routery odbierające stosowałyby do tej aktualizacji maskę klasy /24.

7.2 Konfiguracja protokołu RIPv2

7.2.1 Włączanie i sprawdzanie protokołu RIPv2

Strona 1:

Porównanie formatów komunikatów RIPv1 i RIPv2

Protokół RIPv2 został zdefiniowany w dokumencie RFC 1723. Tak jak wersja 1, RIPv2 jest enkapsulowany w segmencie pakietu UDP, wykorzystuje port 520 i może przenosić do 25 tras. Mimo że podstawowy format jest taki sam, w protokole RIPv2 pojawiły się dwa istotne rozszerzenia.

Pierwszym istotnym rozszerzeniem w formacie komunikatu RIPv2 jest pole z maską podsieci pozwalające na wzbogacenie wpisu trasy RIP o informację o 32-bitowej masce. W efekcie router odbierający, ustalając maskę podsieci dla trasy, nie musi już opierać się ani na masce podsieci interfejsu wyjściowego, ani na masce klasy.

Drugim istotnym rozszerzeniem jest adres następnego skoku. Służy do identyfikacji lepszego adresu następnego skoku - jeśli takowy istnieje - niż adres routera wysyłającego. Jeśli w polu tym są same zera (0.0.0.0), najlepszym adresem następnego skoku jest adres routera wysyłającego. Szczegółowe informacje na temat używania adresu następnego skoku są poza programem tego kursu. Przykład można znaleźć w dokumencie RFC 1722 lub w książce Routing TCP/IP Volume 1 autorstwa Jeffa Doyle'a.

Strona 2:

Wersja 2

Kiedy konfigurujemy na routerze Cisco proces RIP, domyślnie jest to RIPv1. Mimo że router wysyła tylko komunikaty RIPv1, potrafi przetwarzać zarówno komunikaty RIPv1, jak i RIPv2. Router RIPv1 po prostu ignoruje we wpisie trasy pola protokołu RIPv2.

Kliknij R2 RIPv1 na ilustracji.

Polecenie show ip protocols sprawdza, że na routerze R2 skonfigurowano RIPv1, ale urządzenie odbiera komunikaty RIP dla obu wersji.

Kliknij Konfigurowanie RIPv2 na ilustracji.

Zwróć uwagę, że polecenie version 2 jest używane do modyfikacji protokołu RIP, aby używał wersji 2. Polecenie to należy skonfigurować na wszystkich routerach w domenie routingu. Proces RIP będzie od tego momentu we wszystkich aktualizacjach umieszczał maskę podsieci, dzięki czemu RIPv2 będzie bezklasowym protokołem routingu.

Kliknij R2 RIPv2 na ilustracji.

Jak widzimy, po skonfigurowaniu na routerze wersji 2 protokołu RIP wysyłane i odbierane są tylko komunikaty RIPv2.

Kliknij Powrót do RIPv1 na ilustracji.

Domyślny protokół RIPv1 można przywrócić, wydając w trybie konfiguracji routera polecenie no version. Polecenie version 1 może również zostać wydane, aby wysyłane i odbierane były komunikaty tylko RIPv1.

7.2.2 Protokół RIPv2 a automatyczne podsumowanie

Strona 1:

Badanie tablic routingu

Ponieważ RIPv2 to bezklasowy protokół routingu, można by oczekiwać, że w tablicy routingu zobaczymy poszczególne podsieci 172.30.0.0. Jednak gdy zajrzymy do tablicy routingu routera R2, nadal widzimy sumaryczną trasę 172.30.0.0/16 z tymi samymi dwiema równorzędnymi drogami. Routery R1 i R3 nadal nie uwzględniają podsieci 172.30.0.0 tego drugiego routera.

Kliknij Trasy R1 na ilustracji.

Jak dotąd jedyną różnicą pomiędzy RIPv1 i RIPv2 jest to, że routery R1 i R3 mają trasę do supersieci 192.168.0.0/16. Trasa ta jest trasą statyczną skonfigurowaną na routerze R2 i redystrybuowaną przez protokół RIP.

Kliknij Debugowanie 1 R1 na ilustracji.

Co się dzieje? Aby zbadać, które trasy RIPv2 są wysyłane i odbierane, użyjemy polecenia debug ip rip. Na ilustracji pokazano wynik polecenia debug ip rip na routerze R1. Jak widzimy, RIPv2 wysyła zarówno adres sieciowy, jak i maskę podsieci:

RIP: sending v2 update to 224.0.0.9 via Serial0/0 (209.165.200.230)
172.30.0.0/16 via 0.0.0.0, metric 1, tag 0

Widzimy jednak, że wysyłana trasa to zsumowany adres sieci klasowej 172.30.0.0/16, a nie poszczególne podsieci 172.30.1.0/24 i 172.30.2.0/24.

Kliknij auto-podsumowanie na ilustracji.

Domyślnie RIPv2 automatycznie podsumowuje sieci na granicach dużych sieci tak jak RIPv1. Zarówno R1, jak i R3 wysyłając aktualizacje ze swoich interfejsów znajdujących się odpowiednio w sieciach 209.165.200.228 i 209.165.200.232 nadal podsumowują swoje podsieci 172.30.0.0 do adresu klasy B 172.30.0.0. Polecenie show ip protocols potwierdza, że „automatyczne podsumowanie sieci jest włączone” („automatic network summarization is in effect”).

Kliknij Debugowanie 2 R1 na ilustracji.

Jedyną zmianą wynikającą z wydania polecenia version 2 jest to, że router R2 umieszcza w swoich aktualizacjach sieć 192.168.0.0/16. Przyczyną jest to, że RIPv2 wraz z adresem sieciowym 192.168.0.0 umieszcza w aktualizacji maskę 255.255.0.0. Teraz routery R1 i R3 otrzymują dzięki protokołowi RIPv2 redystrybuowaną trasę statyczną i wpisują ją do swoich tablic routingu.

Uwaga: Przypomnijmy, że trasy 192.168.0.0/16 nie można było dystrybuować za pomocą protokołu RIPv1, ponieważ maska podsieci była mniejsza od maski klasy. Ponieważ w aktualizacjach RIPv1 nie ma informacji o masce, protokół RIPv1 nie potrafił jej ustalić. Dlatego aktualizacja nie została nigdy wysłana.

7.2.3 Wyłączanie automatycznego podsumowania w protokole RIPv2

Strona 1:

Jak widzimy na ilustracji, aby zmodyfikować domyślne automatyczne podsumo-wanie dla protokołu RIPv2, w trybie konfiguracji routera należy wydać polecenie no auto-summary. Polecenia tego nie możemy użyć dla protokołu RIPv1. Mimo że system Cisco IOS pozwala skonfigurować polecenie no auto-summary dla protokołu RIPv1, polecenie to nie daje żadnych efektów Zanim system IOS zmieni sposób wysyłania aktualizacji RIP, należy również skonfigurować polecenie version 2.

Po wyłączeniu automatycznego podsumowania protokół RIPv2 już nie podsumowuje sieci do adresów klasowych na routerach brzegowych. RIPv2 od tej chwili umieszcza w aktualizacjach routingu wszystkie podsieci i odpowiadające im maski. Polecenie show ip protocols może byc użyte aby potwierdzić, że „automatyczne podsumowanie jest wyłączone” („automatic network summarization is not in effect”).

7.2.4 Sprawdzanie aktualizacji RIPv2

Strona 1:

Teraz, gdy używamy już bezklasowego protokołu routingu RIPv2, a podsumowanie automatyczne zostało wyłączone, co powinniśmy zobaczyć w tablicy routingu?

Tablica routingu routera R2 zawiera teraz poszczególne podsieci 172.30.0.0/16. Widzimy też, że pojedyncza trasa sumaryczna z dwiema równorzędnymi drogami już nie istnieje. Każda podsieć i maska mają teraz własne wpisy, w których znajdują się również interfejs wyjściowy i adres następnego skoku na drodze do tej podsieci.

Kliknij Trasy R1 na ilustracji.

Tablica routingu routera R1 zawiera wszystkie podsieci 172.30.0.0/16, w tym podsieci routera R3.

Kliknij Trasy R3 na ilustracji.

Tablica routingu routera R3 zawiera wszystkie podsieci dla 172.30.0.0/16, w tym również podsieci od routera R1. Ta sieć osiągnęła pełną zbieżność.

Kliknij Debugowanie R2 na ilustracji.

Używając polecenia debug ip rip, możemy sprawdzić, czy bezklasowy protokół routingu, czyli RIPv2, faktycznie wysyła i odbiera aktualizacje routingu zawierające poszczególne trasy z maskami podsieci, a nie jedną trasę sumaryczną z maską klasy. Zwróćmy uwagę, że w każdym wpisie trasy jest teraz maska podsieci zapisana w notacji ukośnikowej.

Widzimy również, że dla aktualizacji odebranej na jednym interfejsie przed wysłaniem jej z innego interfejsu zwiększana jest metryka. Na przykład aktualizacja odebrana na interfejsie S0/0/1 dla sieci 172.30.100.0/24 z metryką jednego skoku jest wysyłana z innego interfejsu, na przykład S0/0/0, z metryką dwóch skoków.

RIP: received v2 update from 209.165.200.234 on Serial0/0/1
172.30.100.0/24 via 0.0.0.0 in 1 hops
RIP: sending v2 update to 224.0.0.9 via Serial0/0/0 (209.165.200.229)
172.30.100.0/24 via 0.0.0.0, metric 2, tag 0

Zwróćmy też uwagę, że aktualizacje są wysyłane na grupowy adres 224.0.0.9. RIPv1 wysyła aktualizacje na rozgłoszeniowy adres 255.255.255.255. Używanie adresu grupowego daje kilka korzyści. Ich omówienie wykracza poza program tego kursu, jednak ogólnie rzecz biorąc, komunikaty grupowe zajmują mniej pasma sieciowego. Poza tym wysyłanie aktualizacji jako komunikatów grupowych wymaga mniej obliczeń od urządzeń, na których nie działa protokół RIP. Gdy używamy protokołu RIPv2, każde urządzenie, na którym nie skonfigurowano protokołu RIP, odrzuci ramkę w warstwie łącza danych. W przypadku aktualizacji rozgłoszeniowej w konfiguracjach RIPv1 wszystkie urządzenia w sieci rozgłoszeniowej takiej jak Ethernet muszą przetwarzać aktualizację RIP aż do warstwy transportu, kiedy to urządzenie w końcu odkrywa, że pakiet jest przeznaczony dla procesu, który nie istnieje.

7.3 VLSM i CIDR

7.3.1 Protokół RIPv2 a VLSM

Strona 1:

Ponieważ bezklasowe protokoły routingu takie jak RIPv2 mogą przenosić zarówno adres sieciowy, jak i maskę podsieci, nie muszą sumaryzować tych sieci do adresów klasowych na granicach dużych sieci. Tym samym bezklasowe protokoły routingu obsługują VLSM. Routery stosujące RIPv2 nie muszą już używać maski interfejsu wejściowego, aby ustalić maskę podsieci dla ogłaszanej trasy. Sieć i maska są jawnie określone w każdej aktualizacji routingu.

W sieciach używających schematu adresowania VLSM bezklasowy protokół routingu ma krytyczne znaczenie dla propagacji wszystkich sieci z prawidłowymi maskami podsieci. Patrząc na wyniki polecenia debug ip rip dla R3, można zobaczyć, że RIPv2 zawiera sieci i ich maski podsieci w aktualizacjach routingu.

Na rysunku ponownie dodaliśmy do topologii tymczasowo router R4. Przypomnijmy sobie, że w przypadku protokołu RIPv1 router R3 wysyła do routera R4 tylko te trasy 172.30.0.0, które mają taką samą maskę jak interfejs wyjściowy Fa0/0. Ponieważ interfejs ten ma adres 172.30.100.1 z maską /24, protokół RIPv1 uwzględniał tylko podsieci 172.30.0.0 z maską /24. Jedyną trasą spełniającą ten warunek była 172.30.110.0.

Jednak w przypadku protokołu RIPv2 router R3 może w swoich aktualizacjach routingu wysyłanych do routera R4 uwzględniać wszystkie podsieci 172.30.0.0, o czym przekonuje nas wynik polecenia debug. Dzieje się tak dlatego, że RIPv2 może wysyłać w aktualizacji wraz z adresem sieciowym prawidłową maskę podsieci.

7.3.2 Protokół RIPv2 a CIDR

Strona 1:

Jednym z celów routingu CIDR, o którym wspomniano w dokumencie RFC 1519, jest „utworzenie mechanizmu agregowania informacji o trasach”. Założenie to obejmuje koncepcję supersieci. Supersieć to blok ciągłych sieci klasowych adresowanych jako jedna sieć. Na routerze R2 skonfigurowaliśmy supersieć - trasę statyczną do jednej sieci reprezentującą wiele sieci lub podsieci.

Supersieci mają maski krótsze od masek klasowych (w tym przypadku /16 zamiast /24). Aby supersieć znalazła się w aktualizacji routingu, protokół routingu musi umieć wysyłać informacje o tej masce. Innymi słowy, musi to być bezklasowy protokół routingu, na przykład RIPv2.

Trasa statyczna, która została skonfigurowana na routerze R2, ma maskę krótszą niż maska klasy:

R2(config)#ip route 192.168.0.0 255.255.0.0 Null0

W środowisku klasowym adres sieciowy 192.168.0.0 zostałby skojarzony z maską klasy C /24, czyli 255.255.255.0. W dzisiejszych sieciach adresy sieciowe nie są już kojarzone z maskami klas. W tym przykładzie sieć 192.168.0.0 ma maskę /16, czyli 255.255.0.0. Trasa ta może reprezentować sieci 192.168.0.0/24 lub dowolną liczbę różnych przedziałów adresów. Jedynym sposobem na dołączenie tej trasy do dynamicznej aktualizacji routingu jest użycie bezklasowego protokołu routingu, który dołączy maskę /16.

Kliknij Debugowanie R2 na ilustracji.

Gdy wydamy polecenie debug ip rip, zobaczymy, że ta sieć CIDR jest uwzględniana w aktualizacji routingu wysyłanej przez router R2 Aby supersieci były uwzględniane w aktualizacjach, nie trzeba wyłączać automatycznego podsumowania ani dla protokołu RIPv2, ani dla innego bezklasowego protokołu routingu.

Kliknij Trasy R1 na ilustracji.

Widzimy, że w tablicy routingu routera R1 została zapisana otrzymana od routera R2 informacja o supersieci.

7.4 Sprawdzanie działania i rozwiązywanie problemów z protokołem RIPv2

7.4.1 Polecenia do sprawdzania i rozwiązywania problemów

Strona 1:

Istnieje kilka sposobów sprawdzania i rozwiązywania problemów z protokołem RIPv2. Wielu poleceń dla protokołu RIPv2 można używać do sprawdzania działania i rozwiązywania problemów z innymi protokołami routingu.

Zawsze najlepiej rozpoczynać od podstaw:

1. Upewnić się, że wszystkie łącza (interfejsy) są włączone i działają.

2. Sprawdzić kable.

3. Sprawdzić, czy na każdym interfejsie są prawidłowy adres IP i maska podsieci.

4. Usunąć wszystkie polecenia konfiguracyjne, które nie są już potrzebne albo zostały zastąpione innymi poleceniami.

Kliknij show ip route na ilustracji.

Polecenie show ip route jest pierwszym poleceniem używanym do sprawdzania zbieżności sieci. Analizując tablicę routingu, należy pamiętać o wyszukaniu tras, które powinny znajdować się w tablicy routingu, jak również tych, których nie powinno w niej być.

Kliknij show ip interface brief na ilustracji.

Jeśli w tablicy routingu nie ma informacji o jakiejś sieci, często przyczyną jest wyłączony lub źle skonfigurowany interfejs. Polecenie show ip interface brief szybko sprawdza stan wszystkich interfejsów.

Kliknij show ip protocols na ilustracji.

Polecenie show ip protocols sprawdza kilka krytycznych elementów, w tym czy protokół RIP jest włączony, wersję protokołu RIP, stan automatycznego podsumowania oraz sieci, które znalazły się w poleceniach network. W sekcji Routing Information Sources znajdującej się na końcu wyników wymienieni są sąsiedzi RIP, od których router odbiera obecnie aktualizacje.

Kliknij debug ip rip na ilustracji.

Jak można zauważyć w ciągu całego rozdziału, debug ip rip jest doskonałym poleceniem do badania zawartości aktualizacji routingu, które są wysyłane i odbierane przez router. Czasami zdarza się, że router odbiera informacje o trasie, ale nie wprowadza ich do tablicy routingu. Jednym z powodów może być to, że dla tej samej ogłaszanej sieci skonfigurowana jest również trasa statyczna. Domyślnie trasa statyczna ma niższą odległość administracyjną niż jakikolwiek protokół routingu dynamicznego, dlatego ma pierwszeństwo w kolejce do umieszczenia w tablicy routingu.

Kliknij ping na ilustracji.

Łatwym sposobem sprawdzenia łączności w obie strony jest użycie polecenia ping. Jeśli nie ma łączności pomiędzy punktami końcowymi, rozpoczynamy od użycia polecenia ping dla interfejsów lokalnych. Jeśli wynik będzie pozytywny, wysyłamy sygnał ping do interfejsu zdalnego routera w sieciach połączonych bezpośrednio. Jeśli to też się udaje, kontynuujemy wysyłanie sygnału ping do interfejsów kolejnych routerów. Jeśli proces się nie powiedzie, badamy oba routery i wszystkie routery po drodze, aby ustalić gdzie tak się dzieje i dlaczego.

Kliknij show running-config na ilustracji.

Polecenie show running-config jest ostatnim, jakiego należy użyć do sprawdzania i diagnozowania konfiguracji. Zazwyczaj inne polecenia są wydajniejsze i wyświetlają więcej informacji niż prosty wykaz bieżącej konfiguracji. Jednak za pomocą polecenia show running-config można sprawdzić wszystkie skonfigurowane aktualnie polecenia.

7.4.2 Najczęściej spotykane problemy z protokołem RIPv2

Strona 1:

Rozwiązując problemy z protokołem RIPv2, należy skupić się na kilku obszarach.

Wersja

Rozwiązywanie problemów z działaniem sieci warto rozpocząć od sprawdzenia, czy na wszystkich routerach zostało skonfigurowane polecenie version 2. Mimo że używając dodatkowych, nieomawianych na tym kursie, poleceń, można skonfigurować kompatybilność protokołów RIPv1 i RIPv2, RIPv1 nie obsługuje nieciągłych podsieci, VLSM ani supersieci CIDR. Zawsze lepiej używać tego samego protokołu routingu na wszystkich routerach, o ile nie istnieje naprawdę konkretny powód, aby postępować inaczej.

Polecenia network

Kolejną przyczyną problemów mogą być nieprawidłowo skonfigurowane lub brakujące polecenia network. Przypomnijmy, że polecenie network odpowiada za dwie sprawy:

• pozwala protokołowi routingu wysyłać i odbierać aktualizacje na wszystkich interfejsach lokalnych należących do danej sieci,

• umieszcza informacje o skonfigurowanej sieci w aktualizacjach routingu wysyłanych do sąsiednich routerów.

Efektem brakujących lub nieprawidłowych poleceń network są brakujące aktualizacje routingu lub niewysyłanie albo nieodbieranie aktualizacji routingu na danym interfejsie.

Podsumowanie automatyczne

Jjeśli konieczne jest wysyłanie informacji o konkretnych podsieciach, a nie tylko tras sumarycznych, należy sprawdzić, czy podsumowanie automatyczne zostało wyłączone.

7.4.3 Uwierzytelnianie

Strona 1:

Większość protokołów routingu wysyła aktualizacje routingu i inne informacje o trasach za pomocą protokołu IP (używając pakietów IP). Istotnym wyjątkiem, omówionym na kursie CCNP, jest protokół IS-IS. Niezależnie od używanego protokołu routingu istnieje możliwość, że przesyłane będą nieprawidłowe aktualizacje routingu. Źródłem tych nieprawidłowych aktualizacji może być napastnik usiłujący złośliwie zakłócić działanie sieci albo przechwycić pakiety, zmuszając router do wysyłania aktualizacji do nieodpowiedniego celu. Kolejną przyczyną nieprawidłowych aktualizacji może być źle skonfigurowany router. Albo nawet zwykły komputer, na którym bez wiedzy użytkownika włączony jest protokół routingu.

Przykład widzimy na rysunku: router R1 do wszystkich pozostałych routerów w tej domenie routingu propaguje trasę domyślną. Jednak ktoś przez pomyłkę dodał do sieci router R4, który również propaguje trasę domyślną. Niektóre routery mogą przekazywać domyślny ruch nie do prawdziwej bramy, ale do routera R4. Pakiety te mogą trafić do czarnej dziury i nigdy już nie powrócić.

Niezależnie od motywacji, warto wyrobić sobie nawyk uwierzytelniania informacji o trasach. Protokoły RIPv2, EIGRP, OSPF, IS-IS i BGP pozwalają na szyfrowanie i uwierzytelnianie informacji o trasach. W ten sposób informacja o trasach jest ukrywana, a routery przyjmują informacje o trasach tylko od tych routerów, na których skonfigurowano takie same hasło lub informację uwierzytelniającą. Uwaga: Uwierzytelnianie nie szyfruje tablicy routingu.

Uwaga: Ponieważ protokół RIP określił założenia do bardziej popularnych protokołów routingu, szczegółowa konfiguracja uwierzytelniania RIPv2 nie jest omawiana w tym rozdziale. Polecenia służące do konfiguracji uwierzytelniania protokołów routingu są omówione na innym kursie razem z innymi kwestiami bezpieczeństwa.

7.6 Podsumowanie rozdziału

7.6.1 Podsumowanie i powtórzenie

Strona 1:

Podsumowanie

RIPv2 jest bezklasowym, opartym na wektorze odległości protokołem routingu, który jest zdefiniowany w RFC 1723. Ponieważ RIPv2 jest bezklasowym protokołem routingu, dołącza maskę podsieci do adresów sieci w aktualizacjach routingu. Tak jak inne bezklasowe protokoły, RIPv2 wspiera supersieci CIDR, VLSM oraz sieci nieciągłe.

Zobaczyliśmy, że klasowe protokoły routingu takie jak RIPv1 mogą nie wspierać nieciągłych sieci ponieważ automatycznie podsumowują sieci na brzegu sieci głównej. Router, który otrzyma aktualizacje od wielu routerów, które ogłaszają tę samą klasową podsumowana trasę, nie mogą określić, która podsieć należy do której sieci. Niezdolność ta może prowadzić do nieprzewidywalnych rezultatów takich jak źle przekierowane pakiety.

Domyślną wersją protokołu RIP jest wersja 1. Polecenie version 2 jest używana do zmiany RIP na RIPv2.

Podobnie jak RIPv1, RIPv2 automatycznie podsumowuje na brzegu sieci głównej. Automatyczne podsumowanie może być wyłączone za pomocą komendy no auto-summary. Automatyczne podsumowanie musi być wyłączone, aby obsługiwać sieci nieciągłe. RIPv2 również wspiera supersieci CIDR i VLSM, ponieważ odpowiednia maska podsieci jest dołączana do adresu sieci w każdej aktualizacji routingu. Można wykorzystać polecenie debug ip rip do sprawdzenia, że RIP przesyła maskę podsieci razem z adresem sieci jako część wpisu routingu.

Polecenie show ip protocols pokaże, że RIP wysyła i odbiera aktualizacje w wersji 2 oraz czy działa podsumowanie tras (automatyczne lub nie).

Strona 4:

Aby nauczyć się więcej

RFC 1723 RIP version 2

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. Protokołowi RIPv2 został poświęcony dokument RFC 1723.

Dokumenty RFC można znaleźć w kilku serwisach, w tym na stronie www.ietf.org. Aby dowiedzieć się więcej na temat tego protokołu, należy przeczytać całość lub fragmenty dokumentu RFC 1723.

9

---