Cisco: RIP

Autor: Arkadiusz Tobiasz 8 maja 2010

Ostatnio pisałem trochę o routingu statycznym, więc w dzisiejszej notce co nieco o routingu dynamicznym. Spróbuję omówić protokół RIP, który zalicza się do protokołów wektora odległości. Routery używające tego protokołu regularnie wysyłają kompletną zawartość swojej tablicy routingu do wszystkich sąsiednich routerów, które te informacje przesyłają dalej. RIP w wersji pierwszej jak i drugiej jest jednym z najstarszych protokołów trasowania. Mimo to są nadal wykorzystywane ze względu na swoją prostotę, popularność i kompatybilność z różnymi rodzajami sprzętu.W protokole RIP metrykę wylicza się poprzez określenie liczby skoków przez kolejne routery na trasie prowadzącej do sieci docelowej. Routery wybierają trasę o najmniejszej liczbie skoków i zapisują ją w tablicy routingu. Jeśli dwie lub więcej tras ma taką samą liczbę skoków, to będą one wszystkie wykazywane w tablicy routingu. Tablica routingu jest rozgłaszana do sąsiednich routerów cyklicznie, domyślnie co 30 sekund.

Powyżej znajduje się topologia naszej sieci, dla której będziemy konfigurować protokół RIP. Zanim jednak do tego przejdziemy przedstawię konfigurację poszczególnych routerów:

Router Gliwice

Router> en

Router# conf t

Router(config)# host Gliwice

Gliwice(config)# int f0/0

Gliwice(config-if)# ip address 192.168.1.1 255.255.255.0

Gliwice(config-if)# no shut

Gliwice(config-if)# exit

Gliwice(config-if)# int f0/1

Gliwice(config-if)# ip address 203.203.3.2 255.255.255.0

Gliwice(config-if)# no shut

Gliwice(config-if)# end

Gliwice# copy running-config startup-config

Router Zabrze

Router> en

Router# conf t

Router(config)# host Zabrze

Zabrze(config)# int f0/0

Zabrze(config-if)# ip address 172.16.16.2 255.255.255.0

Zabrze(config-if)# no shut

Zabrze(config-if)# exit

Zabrze(config-if)# int f0/1

Zabrze(config-if)# ip address 203.203.3.1 255.255.255.0

Zabrze(config-if)# no shut

Zabrze(config-if)# end

Zabrze# copy running-config startup-config

Router Bytom

Router> en

Router# conf t

Router(config)# host Bytom

Bytom(config)# int f0/0

Bytom(config-if)# ip address 192.168.1.2 255.255.255.0

Bytom(config-if)# no shut

Bytom(config-if)# exit

Bytom(config-if)# int f0/1

Bytom(config-if)# ip address 202.202.2.1 255.255.255.0

Bytom(config-if)# no shut

Bytom(config-if)# end

Bytom# copy running-config startup-config

Router Katowice

Router> en

Router# conf t

Router(config)# host Katowice

Katowice(config)# int f0/0

Katowice(config-if)# ip address 202.202.2.2 255.255.255.0

Katowice(config-if)# no shut

Katowice(config-if)# exit

Katowice(config-if)# int f0/1

Katowice(config-if)# ip address 172.16.16.1 255.255.255.0

Katowice(config-if)# no shut

Katowice(config-if)# exit

Katowice(config-if)# int f1/0

Katowice(config-if)# ip address 192.168.13.1 255.255.255.0

Katowice(config-if)# no shut

Katowice(config-if)# end

Katowice# copy running-config startup-config

Router Siemianowice

Router> en

Router# conf t

Router(config)# host Siemianowice

Siemianowice(config)# int f0/0

Siemianowice(config-if)# ip address 192.168.13.2 255.255.255.0

Siemianowice(config-if)# no shut

Siemianowice(config-if)# end

Siemianowice# copy running-config startup-config

Mając skonfigurowane poszczególne interfejsy na routerach w naszej sieci możemy zacząć konfigurować protokół RIP na nich. Rozpoczniemy od routera Siemianowice. Konfiguracja protokołu RIP jest bardzo prosta i wygląda następująco:

Siemianowice# conf t

Siemianowice(config)# router rip

Siemianowice(config-router)# network 192.168.13.0

Dzięki powyższym komendom na routerze Siemianowice uruchomiliśmy proces RIP oraz dodaliśmy do niego przylegającą sieć. Sieć ta będzie wysyłana w tablicy routingu do sąsiedniego routera pod warunkiem, że będzie on miał również uruchomiony proces RIP. W takim razie skonfigurujmy go dla routera Katowice:

Katowice# conf t

Katowice(config)# router rip

Katowice(config-router)# network 192.168.13.0

Katowice(config-router)# network 202.202.2.0

Katowice(config-router)# network 172.16.16.0

W taki oto sposób nasze routery co 30 sekund powinny wymieniać się informacjami o trasach, które są zawarte w ich tablicy routingu. Możemy sprawdzić teraz, czy router Siemianowice posiada informacje o sieciach, do których należy router Katowice. Wywołujemy na routerze Siemianowice komendę:

Siemianowice# show ip route

Jak widzicie na powyższym obrazku nasz router Siemianowice uzyskał informacje o sieciach znajdujących się w tablicy routingu routera Katowice. Trasy, które router Siemianowice poznał od routera Katowice oznaczone są literką R, natomiast literka C oznacza trasy, do których bezpośrednio należy router. Spróbujmy zatem dostać się do sieci 172.16.16.0 z routera Siemianowice:

Siemianowice# ping 172.16.16.1

Udało się, a więc nasz routing dynamiczny działa. Możemy również dowiedzieć się jakie protokoły routingu są aktywne w danym routerze. Robimy to za pomocą komendy:

Siemianowice# show ip protocols

Oprócz tego możemy być informowani o procesach jakie zachodzą na danym routerze, takich jak otrzymywanie pakietów RIP z innych urządzeń, wysyłanie pakietów czy dodawanie nowych tras do tablicy routingu. Robimy to poprzez włączenie debugowanie, jednak debugowanie zwiększa zużycie procesora i pamięci RAM, więc należy z niego korzystać ostrożnie. Pierwsza komenda włącza debugowanie, a kolejna je wyłącza:

Siemianowice# debug ip rip

Siemianowice# undebug all

Nasz router Siemianowice jest połączony tylko z routerem Katowice, więc rozgłaszanie swojej tablicy routingu do routera sąsiedniego jest zbędne. Po prostu nie wnosi ono nic nowego, bo router Katowice posiada informacje o sieci 192.168.13.0, ponieważ do niej należy. W związku z tym możemy skonfigurować interfejs f0/0 routera Siemianowice jako pasywny, gdyż chcemy jedynie odbierać informacje od routera Katowice. W związku z tym wpisujemy komendy:

Siemianowice# conf t

Siemianowice(config)# router rip

Siemianowice(config-router)# passive-interface f0/0

Wersja pierwsza protokołu RIP ma swoje wady, ponieważ nie pozwala na stosowanie CIDR, czyli poszczególne adresy muszą używać masek podsieci charakterystycznych dla danej klasy, do której należą. Dlatego też powstała kolejna wersja protokołu RIP, która daje taką możliwość.

Skonfigurujemy teraz routery Zabrze i Gliwice z wykorzystaniem protokołu RIP w wersji 2.

Router Zabrze

Zabrze# conf t

Zabrze(config)# router rip

Zabrze(config-router)# version 2

Zabrze(config-router)# net 172.16.16.0

Zabrze(config-router)# net 203.203.3.0

Router Gliwice

Gliwice# conf t

Gliwice(config)# router rip

Gliwice(config-router)# version 2

Gliwice(config-router)# net 192.168.1.0

Gliwice(config-router)# net 203.203.3.0

Standardowo sprawdzamy tablicę routingu routera Zabrze:

Zabrze# sh ip route

Pojawiła się tam sieć przekazana z tablicy routingu routera Gliwice. Jednak nie ma w niej informacji o trasach jakie posiada router Katowice. Musimy skonfigurować odpowiednio interfejs f0/1 routera Katowice, aby wysyłał informacje dla protokołu RIP w wersji 2, natomiast odbierał dla RIP w wersji 1 i 2. Robimy to poprzez skonfigurowanie wspomnianego interfejsu:

Katowice# conf t

Katowice(config)# int f0/1

Katowice(config-if)# ip rip send version 2

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

Sprawdźmy tablicę routingu routera Zabrze:

Zabrze# sh ip route


Jak widzicie tablica routingu została zaktualizowana o trasy otrzymane od routera Katowice. W protokole RIP możemy także skonfigurować zegar, który określa m.in. częstotliwość wysyłania aktualizacji tablicy oraz czas przetrzymywania niezaktualizowanej trasy w tablicy routingu. Robimy to za pomocą polecenia:

Router(config-router)#timers basic update invalid holddown flush

gdzie:

  • update to częstotliwość wysyłania aktualizacji
  • invalid to czas po upływie, które niezaktualizowana trasa zmienia stan na holddown i router nadal z niej korzysta
  • holddown to czas przetrzymywania trasy w tablicy routingu po przekroczeniu czasu invalid
  • flush to czas od ostatniej aktualizacji, po którego przekroczeniu trasa jest usuwana z tablicy routingu.

Jeden komentarz

  1. […] uzupełnienie i poszerzenie informacji o protokole RIP, który opisałem jakiś czas temu. Był to swoisty wstęp do routingu dynamicznego, a właściwie do rodziny […]

Odpowiedz

 

Arkadiusz Tobiasz student Akademii Ekonomicznej im. Karola Adamieckiego w Katowicach na specjalnościach informatyka ekonomiczna oraz rachunkowość. Więcej...

jQuery Validation i funkcja remote

Jakiś czas temu zwrócił się do mnie użytkownik z problemem. Chodzi o to, że korzysta on z pluginu walidacji jQuery, […]

Zend Framework: integracja z Uploadify

W tym wpisie postaram się przedstawić Wam w jaki sposób zintegrować skrypt Uploadify z Zend Frameworkiem. Dzięki temu będziemy mogli […]

Javascript: Czasowe wyświetlanie reklamy

Czasami chcemy, aby na pewnym elemencie naszej strony wyświetlała się reklama przez jakiś czas, a następnie zniknęła. W tym wpisie […]

Linux: backup wszystkich baz danych MySQL

Swego czasu pisałem o tym jak z poziomu konsoli można szybko i przyjemnie zrobić backup bazy MySQL. Wszystko jest ładnie […]