Routing dynamiczny/Protokół RIPv2

Z Wikibooks, biblioteki wolnych podręczników.

Protokół RIPv2[edytuj]

Ponieważ jest to obszerny i dość trudny temat, na początku skupmy się nad relatywnie prostym przypadkiem, który może mieć zastosowanie w niejednej przerośniętej sieci osiedlowej.

Przedstawimy w nim przykład zastosowania routingu dynamicznego na bazie protokołu RIPv2. Warto wspomnieć, że wcześniejsza wersja - RIPv1 - był jednym z pierwszych protokołów routingu zastosowanym w sieci Internet. Bardziej rozbudowanym i doskonalszym protokołom z rodziny OSPF i BGP poświęcone będą następne rozdziały.

Zebra to pakiet oprogramowania routingu dynamicznego dla systemów z rodziny *nix . Wspiera protokoły RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, BGP-4, BGP+4. Składa sie z głównego demona zebra, który na podstawie danych dostarczonych przez ripd, ripngd, ospfd, ospf6d, bpgd, modyfikuje tablice routingu jądra systemu. Modularna budowa pozwala rozbudować oprogramowanie rutera o przyszłe, bardziej doskonałe protokoły.

Po skompilowaniu źródeł otrzymujemy m.in. pliki wykonywalne o nazwach wyróżnionych powyżej. Wykonanie skryptu 'make install' umieszcza domyślnie te pliki w folderze /usr/local/sbin/ .

Stamtąd możemy już bezpośrednio je uruchomić. Warto w tym celu utworzyć niewielki skrypt, który za każdym razem przy starcie routera będzie uruchamiać obsługę routingu dynamicznego. Jego treść wystarczająca na potrzeby tego przykładu zamieszczona jest poniżej.


#! /bin/sh

# zamyka poprzednio działające demony
killall ripd; killall zebra

#uruchamia demony - istotna kolejnosc uruchamiania
/usr/local/sbin/zebra -d
/usr/local/sbin/ripd -d

Spowoduje to uruchomienie demonów i odczytanie plików konfiguracyjnych, których demony domyślnie oczekują w folderze /usr/local/etc.

Bezpośrednio po wykonaniu skryptu 'make install' w powyższym folderze znajdują się przykładowe pliki konfiguracyjne (zebra.conf.sample, ripd.conf.sample) dla każdego z demonów. Należy je odpowiednio przeedytować stosownie do konfiguracji sieci, w której router będzie pracować i zapisać pod nazwą zebra.conf oraz ripd.conf.

/usr/local/etc/zebra.conf

Umieszczamy tutaj m.in. dodatkową konfigurację interfejsów sieciowych, aliasowe numery ip, statyczne pozycje tablicy routingu, które dany router bedzie rozglaszal np. poprzez protokół RIPv2 innym routerom, serwerom bądź też stacjom roboczym (lub rozrywkowym :-)) takim jak nasz domowy komputer podłączony do Internetu przez sieć lokalną w bloku.

! zebra sample configuration file

hostname ruterek
password zebra
enable password zebra

! Static default route sample.
ip route 0.0.0.0/0 10.250.0.5

log file /var/log/zebra/zebra.log

Jeżeli nasz ruter posiada już skonfigurowaną statycznie tablicę routingu, nie ma konieczności przenosić jej do pliku zebra.conf . Jednak przeniesienie statycznej tablicy routingu do pliku zebra.conf na pewno pozytywnie wpłynie na ład i porządek w konfiguracji rutera, co w konsekwencji ułatwi odnalezienie przyczyn ewentualnych problemów.

/usr/local/etc/ripd.conf

W tym pliku zamieszczamy opcje związane bezpośrednio z obsługą protokołów RIPv1 oraz RIPv2. Przykładowa konfiguracja zamieszczona jest poniżej.

! RIPd sample configuration file

hostname ripd
password zebra

! wyświetla szczegółowe komunikaty dotyczące działania demonów
debug rip events
debug rip packet
debug rip zebra

router rip
version 2

! oznaczają podsieci lub interfejsy, w których pracuje ruter
network 10.250.0.0/16
network 10.180.0.0/16
network 193.18.201.0/24
network eth0

! polecenie "redistrubute" wskazuje, które trasy mają być rozgłaszane

! rozglasza trasy dodane do kernela nie majace nic wspolnego z konfiguracją
! interfejsów naszego rutera, rozglasza takze trasy do podsieci do których 
! naleza aliasowe numerki ip do interfejsow 
redistribute kernel

! rozgłasza statyczne trasy zdefiniowane w pliku zebra.conf
redistribute static

! rozgłasza trasy do podsieci, w których ruter bezpośrednio pracuje
! poprzez konfiguracje swoich interfejsow (czyli trasy do podsieci oznaczonych
! jako 'scope link' za wyjatkiem aliasowych konfiguracji dla interfejsów
redistribute connect

! wskazuje, gdzie maja byc kierowane logi

log file /var/log/zebra/ripd.log
!log stdout


Tutaj przydałby się jakiś przykład z życia wzięty i odpowiednio ilustrowany.

Gdy juz wszystko bedzie dzialac jak nalezy, nie zapomnijmy wykomentowac wpisow 'debug ...' w ripd.conf . W przeciwnym razie rozrastające się szybko logi zapełnią nam całe wolne miejsce na partycji.