SIECI KOMPUTEROWE I

 

PROTOKOŁY RUTINGU

 

Protokoły routingu (routujące, ang. routing protocols) używane są do wymiany informacji o trasach pomiędzy sieciami komputerowymi, co pozwala na dynamiczną

budowę tablic routingu. Tradycyjne trasowanie jest bardzo proste, bo polega na wykorzystaniu tylko informacji o następnym "przeskoku" (ang. hop ). W tym

przypadku router tylko kieruje pakiet do następnego routera, bez uwzględnienia na przykład zbyt wielkiego obciążenia czy awarii na dalszej części trasy.

Mimo że dynamiczny routing jest bardzo skomplikowany, to właśnie dzięki niemu Internet jest tak elastyczny i rozwinął się o ponad 8 rzędów wielkości w ciągu

ostatnich 30 lat.

 

Metryka routingu jest wartością używaną przez algorytmy routingu do określenia, która trasa jest lepsza. Brane są pod uwagę: szerokość pasma, opóźnienie, ilość

przeskoków, koszt ścieżki, obciążenie, MTU, niezawodność, koszt komunikacji. Tylko najlepsze trasy przechowywane są w tablicach routingu, podczas gdy inne mogą być przechowywane w bazach danych. Jeśli router korzysta z mechanizmów równoważenia obciążenia (ang. load balancing) w tablicy routingu może wystąpić kilka najlepszych tras. Router będzie je wykorzystywał równolegle, rozpraszając obciążenie równomiernie pomiędzy trasami.

 

Wybór protokołu odbywa się na podstawie wartości odległości administracyjnej

 

Podział ze względu na zależności pomiędzy routerami

 

• Protokoły dla sieci o nieskomplikowanej budowie (ang. Ad hoc network routing protocols)

 

• Wewnętrzne protokoły routingu (zwane również protokołami bramy wewnętrznej - IGP, ang. Interior Gateway Protocol) - używane do wymiany informacji o trasach w pojedynczym systemie autonomicznym.

Przykłady:

o IGRP/EIGRP (Interior Gateway Routing Protocol / Enhanced IGRP)

o OSPF (Open Shortest Path First)

o RIP (Routing Information Protocol)

o IS-IS (Intermediate System to Intermediate System)

 

• Zewnętrzne protokoły routingu (zwane również protokołami bramy zewnętrznej - EGP, ang. Exterior Gateway Protocol) - używane do wymiany informacji o trasach pomiędzy różnymi systemami autonomicznymi.

Przykłady:

o EGP (Exterior Gateway Protocol - obecnie przestarzały)

o BGP (Border Gateway Protocol)

 

Podział ze względu na sposób działania

• protokoły routingu wektora odległości - przekazują okresowe kopie tablic routingu do sąsiedniego routera, nie mają pełnej informacji o odległych

routerach, najlepsza ścieżka ustalana jest przez dodawanie do metryki routingu wartości. Przykłady:

o RIP

o IGRP

• protokoły routingu stanu łącza - utrzymują złożone bazy danych z informacjami o topologii, mają pełną informację o odległych routerach, najlepsza ścieżka jest obliczana przez każdy router. Przykłady:

o OSPF

o IS-IS/Integrated IS-IS

o ES-IS

• hybrydowe protokoły routingu - mają cechy zarówno protokołów wektora odległości jak i stanu łącza. Przykłady:

o EIGRP

• protokoły routingu typu path-vector - opisują trasy przy pomocy atrybutów:

o EGP

o BGP

o IDRP

Najczęściej protokoły routingu wektora odległości uaktualniają tablice okresowo (np. RIP) a stanu łącza gdy zmienia się topologia (np. OSPF)

1. Routing statyczny polega na trwałej konfiguracji routerów w ten sposób, że pakiety o podanych adresach są wysyłane są na z góry podany interfejs.

Administrator musi ustalić zasady routingu między wszystkimi sieciami. Dokonuje tego przez budowę tablic routingu na wszystkich routerach.

2. Routing dynamiczny polega na tym, że routery same analizują topologii sieci w której pracują i same ustalają zasady optymalnych połączeń między

sobą. Powinny też wykrywać zmiany w topologii sieci (np. awarie) i automatycznie się do nich dostosować.

3. Routing wewnętrzny jest to routing wykonywany wewnątrz pojedynczego systemu autonomicznego.

 

Routing OSI

Dla zestawu protokołów OSI (Open Systems Interconnection) opracowano w ramach organizacji ISO (International Standard Organization) kompletny zbiór protokołów routingu. Są to: ES-IS (End System-to-Intermediate System), IS-IS (Intermediate System-to-Intermediate System) i IDRP (Interdomain Routing Protocol).

 

Wymienione protokoły zostały opisane w następujących dokumentach wydanych przez ISO:

 

Działanie routingu OSI

  1. Routing OSI rozpoczyna się z chwilą, gdy systemy ES odbierając pakiety ISH zidentyfikują najbliższy system IS.
  2. System ES, chcąc wysłać pakiet do innego systemu ES, wysyła pakiet do jednego bezpośrednio z nim połączonych systemów IS.
  3. System IS (router) sprawdza adres miejsca przeznaczenia i wysyła pakiet przez najlepszą ścieżkę.
  4. Jeśli adres wskazuje docelowy system ES w tej samej podsieci, o czym router wie dzięki zebranej informacji, to wybierze odpowiednią trasę wewnątrz podsieci.
  5. Jeśli adres wskazuje docelowy system ES w innej podsieci tego samego obszaru, to router również będzie znał prawidłową trasę.
  6. Jeśli adres wskazuje docelowy system ES w innym obszarze, to router poziomu 1 wysyła pakiet do najbliższego routera poziomu 2.
  7. Przesyłanie przez routery poziomu 2 trwa tak długo, aż pakiet dotrze do routera w obszarze docelowego sytemu ES.
  8. W obszarze docelowego systemu ES router wysyła pakiet do właściwego systemu ES. Systemy IS poznają topologię sieci, używając komunikatów uaktualniania stanu łącz (link-state update message).

Protokół ES-IS

Protokół ES-IS definiuje współdziałanie systemów ES (hostów) i systemów IS (routerów) w zbieraniu informacji o sobie, czyli proces nazwany konfigurowaniem. Konfigurowanie musi nastąpić przed pojawieniem się routingu. W trakcie tego procesu zostają ustalone adresy sieciowe innych węzłów.

Grafika:Osi2.jpg

 

Rodzaje połączeń ES-IS

Protokół ES-IS jest raczej protokołem poszukiwawczym (discovery) niż protokołem routingującym. Rozróżnia się trzy typy podsieci:

Konfigurowanie ES-IS

Konfigurowanie ES-IS jest procesem, podczas którego oba systemy wzajemnie się rozpoznają w celu umożliwienia routingu pomiędzy nimi. W tym procesie są wymieniane w regularnych odstępach czasu dwa rodzaje komunikatów typu hello: ESH (ES hello message) i ISH (IS hello message). Komunikaty ESH są generowane przez systemy ES i wysyłane do wszystkich systemów IS w podsieci, podobnie komunikaty ISH są generowane przez systemy IS i wysyłane do wszystkich systemów ES w podsieci. Dzięki tym komunikatom systemy mogą rozpowszechniać generowane przez siebie adresy podsieci i warstwy sieciowej. Jeśli tylko jest to możliwe, komunikaty te są rozsyłane jednocześnie do wszystkich systemów.

Protokół IS-IS

IS-IS jest protokołem typu "link-state", który rozpowszechnia informacje o stanie łącz w celu utworzenia kompletnego obrazu topologii sieci (porównaj protokół OSPF). Aby umożliwić uproszczenie budowy routerów, protokół IS-IS wyróżnia systemy IS poziomu 1 i poziomu 2 (Level 1 router i Level 2 router). Routery poziomu 1 łączą ze sobą systemy w jednym obszarze, routery poziomu 2 łączą obszary między sobą, tworząc szkielet wewnątrzdomenowy.

Miary protokołu IS-IS

Protokół IS-IS używa jednej domyślnej miary, której wartość nie przekracza 1024. Miarę przydziela administrator sieci. Pojedyncze łącze może przyjąć wartość nie większą niż 64, wartość ścieżki uzyskuje się sumując wartości łączy.

Protokół IS-IS definiuje również trzy miary opcjonalne: opóźnienie (delay), wydatek (expense) i błąd (error). Miara kosztu opóźnienia odzwierciedla wielkość opóźnienia wprowadzanego przez łącze. Miara wydatku odzwierciedla koszty ponoszone na użycie łącza. Miara błędu wskazuje stopę błędów na danym łączu. Protokół IS-IS odwzorowuje wymienione cztery miary w opcji QoS nagłówka pakietu CLNP (Connectionless Network Protocol), używając tego odwzorowania do wyznaczenia tras w sieci.

Protokół IDRP

IDRP (Interdomain Routing Protocol) jest protokołem OSI, który specyfikuje komunikację pomiędzy routerami w różnych domenach. Jest to protokół kategorii "link-state", służący do routingu w trybie bezpołączeniowym, współdziała z protokołami CLNP, ES-IS i IS-IS. Projekt protokołu IDRP oparto na protokole BGP.

Podstawowe właściwości protokołu IDRP

Protokół IDRP zapewnia:

  • usługi QoS (Quality of service) dla protokołu CLNP,
  • likwidację pętli,
  • zmniejszenie informacji o trasach i zapotrzebowanie na moc obliczeniową,
  • wysoką niezawodność,
  • bezpieczeństwo dzięki użyciu szyfrowanych podpisów.

Routing protokołu IDRP

 

Komunikacja między domenami

Trasa protokołu IDRP jest sekwencją identyfikatorów RDI, przy czym niektóre z nich mogą dotyczyć konfederacji. Każda baza danych BIS jest skonfigurowana tak, by "znać" domenę lub konfederację, do której należy. W celu zdobycia wiedzy o sąsiednich domenach wymienia z nimi informacje.

Podobnie jak w routingu "distance-vector" trasy do określonego miejsca przeznaczenia mają widok zewnętrzny z miejsca przeznaczenia. Do innych systemów BIS będą prowadziły tylko te trasy, które zostały uprzednio wybrane i które spełniają wymagania strategii lokalnych systemów BIS. Zmiana trasy może być tylko częściowa i ma miejsce, gdy zajdzie jedno z następujących zdarzeń:

 

Protokół RIP

Protokół RIP jest protokołem zaliczanym do protokołów z wykorzystaniem wektora odległości i bazuje na algorytmie Bellmana-Forda. Protokół ten bazuje na otwartych standardach i charakteryzuje się prostotą implementacji. Protokół RIP w wersji 1 jest opisany w RFC2453, a w wersji drugiej w RFC1058. RIP w wersji 1 jest klasowym protokołem routingu, dopiero wersja 2 tego protokołu jest protokołem bezklasowym. Inne elementy wprowadzone w wersji 2 to:

W celu zapobieżenia nieskończonym pętlom routingu w protokole RIP ograniczono liczbę dopuszczalnych przeskoków na ścieżce od źródła do celu. Maksymalna liczba przeskoków na ścieżce wynosi 15. Protokół RIP rozsyła cykliczne aktualizacje. W każdej aktualizacji rozgłaszana jest odległość do danej sieci, która rozsyłana jest do sąsiednich routerów. Po otrzymaniu przez router aktualizacji routingu, która zawiera nową albo zmienioną pozycję, wartość metryki zostaje zwiększona o 1, aby uwzględnić siebie jako przeskok na ścieżce. Jeśli wartość metryki przekroczy 15, cel w sieci jest uznawany za niedostępny. Protokół RIP realizuje również szereg funkcji, które występują w innych protokołach routingu. Na przykład zaimplementowano w nim mechanizmy split horizon i przetrzymania, które to mechanizmy mają zapobiec propagacji nieprawidłowych informacji o routingu.

RIP (Routing Information Protocol) jest jednym z pierwszych, szeroko wykorzystywanych protokołów routingu IGP (Interior Gateway Protocol). Protokół RIPv1 został opisany w standardzie RFC1058 w 1988 roku, jest implementacją algorytmu Bellman-Ford (Distance-Vector) dla sieci LAN. Protokół RIP klasyfikuje routery jako aktywne i pasywne (ciche). Aktywne routery RIP rozgłaszają swoje trasy lub informacje o dostępności do innych routerów RIP. Routery pasywne RIP słuchają i aktualizują swoje trasy w oparciu o informacje rozgłaszane przez aktywne routery RIP, ale same nie rozgłaszają ich. 

W typowych zastosowaniach, routery mają protokół RIP ustawiony w trybie aktywnym, a hosty w trybie pasywnym. Routery z uruchomionym protokołem RIP w trybie aktywnym, rozgłaszają aktualizacje (broadcast update) w pewnych interwałach. Każdy update protokołu RIP składa się z pary wartości zawierających: sieciowy adres IP i całkowity dystans do tej sieci, czyli metrykę.

Protokół RIP (Routing Information Protocol) stosuje metryki zliczania ilości skoków w celu pomiaru odległości do przeznaczenia. W metryce RIP, router rozgłasza sieci przyłączone bezpośrednio z metryką „1” . Sieci, które są osiągalne przez inny router mają metrykę „2”, a sieci osiągalne przez dwa routery mają metrykę „3” (trzy skoki), itd. Wykorzystanie ilości skoków w celu skalkulowania najkrótszej ścieżki, nie zawsze daje optymalny rezultat. Biorąc za przykład: ścieżka z metryką „3”, która przechodzi przez trzy sieci Ethernet, może się okazać znacząco szybsza od ścieżki z metryką „2”, przechodzącej przez dwie linie szeregowe, małej szybkości.

W celu skompensowania różnic w technologiach, wiele routerów rozgłasza sztucznie metryki o wysokich wartościach dla wolnych łączy. Tabela routingu w RIP jest budowana dynamicznie, w oparciu o informacje otrzymane z updatów protokołu  RIP. Kiedy protokół RIP jest uruchamiany, wysyła żądanie (REQUEST) informacji o routingu i słucha odpowiedzi na swoje żądanie. Jeśli system jest skonfigurowany tak by słyszał żądania RIP, to odpowiada pakietem RESPONSE bazując na informacji z własnej bazy danych o routingu. Pakiet RESPONSE zawiera adres sieciowy i metrykę dla każdego przeznaczenia. Kiedy pakiet RESPONSE zostanie odebrany, protokół RIP bierze tą informacje i przebudowuje bazę danych routingu, dodając nowe trasy i lepsze trasy (te o niższej metryce) do przeznaczeń już istniejących w bazie danych.

Protokół RIP (Routing Information Protocol) także kasuje trasy z bazy danych, jeśli następny router do tego przeznaczenia informuje, że trasa zawiera więcej niż 15 skoków lub jeśli trasa jest skasowana (juz nie istnieje). Ponadto, wszystkie trasy osiągalne przez dany gateway są kasowane, jeśli nie zostanie odebrany update od niego w ściśle wyznaczonym czasie. W implementacji RIP (Routing Information Protocol) przyjęto, że updaty routingu są wysyłane co 30 sekund. W wielu implementacjach, jeśli gateway nie odzywa się przez dłużej niż 180 sek., to wszystkie trasy z tego gatewaya są kasowane z bazy danych routingu (tabeli routingu). Te 180 sekund dotyczy także kasowania określonych tras.

Split Horizon

RIP stosuje mechanizm Split Horizon. Można spotkać dwie implementacje tego mechanizmu: "Split Horizon" i "Split horizon with poison reverse". Pierwszy z nich powoduje, że w aktualizacjach protokołu RIP wysyłanych do sąsiada nie będą włączane trasy nauczone od tego sąsiada, co zapobiega pętlom między dwoma sąsiadami. Druga metoda z "poison reverse" wysyła w wiadomościach aktualizacyjnych trasy nauczone od danego sąsiada, ale z metryką 16 (czyli sieć nieosiągalna). Poison reverse jest więc efektywniejsze i niezależne od timerów RIP, ale RP zużywa wtedy więcej pasma w sieci.

Triggered Updates

RIP wykorzystuje też w swojej implementacji Triggered Updates, czyli jeśli pojawią sie jakiekolwiek zmiany w metrykach (w tabeli routingu RIP), to RIP wymusza wusłanie wiadomości aktualizacyjnej (update), nie czekając na upływ timera 30 sekundowego dla tego typu wiadomości. Zmniejsza to czas istnienia w sieci pętli routingu.

Format wiadomości RIP

RIP wykorzystuje protokół UDP i numer portu 520 by wymieniać wiadomości między routerami. Maksywalna wielkość pakietu RIP wynosi 512 bajtów (bez nagłówków IP i UDP).

Kolejne wersje RIP

RIPv1 (RFC1058) został zastąpiony przez RIPv2 w 1993 roku ze względu na dość znaczne ograniczenia tj. brak bezpiecznej komunikacji między routerami i brak możliwości pracy w trybie bezklasowym IP. Żadna z wersji RIP, niestety, nie nadaje się do implementacji w sieciach, w których liczba skoków, wektor odległości jest większy od 15. W takich sieciach należy stosować protokoły typu link-state, do których zaliczamy OSPF i IS-IS.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Logowanie na serwer:

login: admin

brak hasła

<tab> -2xtabulator wyświetla polecenia dostępne na danym poziomie

.. -powrót o poziom wyżej

> -polecenia wpisywane na mikrotik'u

# -polecenia wpisywane na komputerze stacjonarnym (sys. Linux)

 

Hierarchiczna konstrukcja polecen.

Wycofanie do poziomu nadrzednego:

..

Odwołanie do polecenia z poziomu nadrzednego poprzez / np :

/system reset

 

Polecenie sprawdzajace adresy ip :

Ip address> print

 

Dodanie nowego adresu:

ip address> add

adress: 192.168.10.15/24

interface: ether1

 

Dodawanie z poziomu nadrzednego dla ip address :

Ip> add address= 192.168.10.15/24 interface=ether1 broadcast=192.168.15.254

 

Blokowanie/Odblokowanie adresu :

Ip address> disable 1

Ip address> enable 1

(cyfra jest numerem przyporzadkowanym adresowi, można ja sprawdzic poleceniem print, które wypisze adresy)

 

Edytowanie adresu:

Ip address> Set 1 interface=ether1

 

 

 

KONFIGURACJA DHCP NA MIKROTIKU (1)

 

Widok po wywołaniu polecenia print :

> address network broadcast interface

1 192.168.10.15/24 192.168.10.0 192.168.10.255 ether1

 

Ustawiamy adres IP na komputerze hosta

# ifconfig eth1 192.168.10.15/24

 

Konfiguracja serwera DHCP na Mikrotiku.

 

Ustawiamy zakres przydzielanych adresów:

> ip pool add

name: dhcp-pool

ranges: 192.168.10.18-192.168.10.111

 

Ustawiamy siec w jakiej serwer bedzie działał oraz wpisujemy serwery DNS

> ip dhcp-server network add address=192.168.10.0/24 gateway=192.168.10.1

dns-server=11.11.11.11,11.22.33.44

 

Dodajemy serwer DNS

> ip dhcp-server add interface=ether1 address-pool-dhcp-pool

 

Restartujemy interfejsy hosta

#service network restart

 

Sprawdzamy czy zostały przydzielone adresy z puli.

podgladamy plik /var/lib/dhclient/dhclient-eth0.leases

 

Sprawdzamy czy otrzymalismy adresy DNS.

podgladamy plik /etc/resolv.conf

 

Przydzielamy statyczny adres dla jednego z klientów. Sprawdzamy komu zostały przydzielone adresy IP

> ip dhcp-server lease print

 

Ustawiamy statyczny adres

> ip dhcp-server lease make static

number: 1

 

KONFIGURACJA DHCP NA MIKROTIKU (2)

 

Resetujemy konfiguracje serwera:

> system > reset-configuration

 

Wyświetlenie dostępnych interfejsów:

> interface > print

 

Wchodzimy do poziomu IP i sprawdzamy adres IP

> ip > address > print

 

Polecenie print pokazało puste pole, wiec ustawiamy adres ip

> ip > address > add

 

Ustawiamy IP na 192.168.10.15 z maska 24 bitowa na interfejsie Ether 2.

Adres logiczny IP można ustawić dodatkowo poleceniem

> ip > address > add address=192.168.15.7/24 interface=ether2

 

Sprawdzamy poprawność wykonanych poleceń wpisując print, które wyświetli

nam przypisane adresy.

> ip > address > print

 

Polecenie enable/disable [numer rekordu] włączamy/wyłączamy dane IP na

interfejsie. Poleceniem 'set' możliwe jest edytowanie wpisów. Zmieniamy

interfejs dla 1 rekordu

> ip > address > set 1 interface=ether1

 

Polecenie remove usuwa dodany rekord. Usuwamy 1 rekord w tabeli

> ip > address > remove 1

 

Ustawiamy na komputerze stacjonarnym IP z podsieci oraz podłączamy do

mikrotik'a, w naszym przypadku do interfejsu ether2:

# ifconfig eth0 192.168.10.16/24

 

Ustawiamy zakres IP przydzielanych przez serwer

> ip > pool > add

name: siec

ranges: 192.168.10.5-192.168.10.66

 

Wchodzimy na poziom DHCP-server i dodajemy server:

> ip > dhcp-server > add

interface: ether2

 

Polecenie print pokazało że server został dodamy ale jest w stanie disable.

poleceniem set dodajemy nasz zakres adresow IP raz włączamy server

> ip > dhcp-server > set 0 address-pool=siec

> ip > dhcp-server > enable 0

 

Resetujemy ustawienia sieciowe na komputerze stacjonarnym:

# service network restart

 

Serwer przydzielił adres IP dla komputera stacjonarnego, w naszym przypadku

np. adres 192.168.10.66. Liste przydzielonych adresów IP można sprawdzić

na MikroTik'u przez polecenie

> ip > dhcp-server > lease > print

 

Aby dany rekord był adresem statycznym zawsze przydzielanym przez serwer

dla danego komputera wpisujemy polecenie:

> ip > dhcp-server > lease > make-static 0

 

Następnie ustawiamy bramę domyślną oraz dodajemy dwa DNS'y

> ip > dhcp-server > network > add address=192.168.10.0/24

gateway=192.168.10.15 dns-serwer=1.2.3.4,5.6.7.8

 

Sprawdzamy poprawność wpisanych poleceń na komputerze stacjonarnym,

resetując ustawienia sieci:

# service network restart

# route -n