ROUTOWANIE (TRASOWANIE) DYNAMICZNE, PROTOKOŁY ROUTOWANIA Sposób obsługi routowania przez warstwę IP nazywa się mechanizmem routowania. Określenie to dotyczy przeglądania przez jądro tablicy routowania i podejmowania określonych decyzji, co do przesyłania datagramów IP. Przez pojęcie polityka routowania określa się działania procesu routowania podejmowane w celu ustanowienia i bieżącej modyfikacji tablicy routowania. Polityka routowania realizowana jest z wykorzystaniem protokołów routowania. Pożądane cechy protokołów routowania to: Wyznaczenie najlepszej trasy do punktu docelowego (the optimal route). Wymaga to m.in. określenia kryterium porównywania tras. Odporność (robustness). Protokoły routowania muszą działać poprawnie w przypadku nieprzewidzianych zdarzeń, np. awarii sprzętowych, niewłaściwych konfiguracji, nagłych dużych obciążeń sieci. Szybkie osiągnięcie zbieżności (rapid convergence). Przez zbieżność rozumie się tutaj osiągniecie stanu, w którym wszystkie routery widzą jednakowo topologię sieci. Szybkość zbieżności rozważa się po zmianie topologii sieci termin ten określa czas rozpowszechnienia informacji o zmianach do wszystkich routerów. Również po włączeniu routera/routerów dobrze byłoby, gdyby jak najszybciej routery ustaliły swoje obrazy sieci (i wynikające z nich tablice routowania). Dopasowanie do zmian (flexibility). Po różnych zmianach, np. odłączeniu pewnej sieci, zmianie szerokości pasma, zmianie opóźnienia itp. router powinien szybko wyznaczyć nowe optymalne trasy. Internet jest zorganizowany jako grupa tzw. systemów autonomicznych AS, z których każdy jest osobno administrowany. Każdy system autonomiczny może stosować własne protokoły routowania, zwane wewnętrznymi protokołami routowania (ang. IGP interdomain gateway protocol lub IRP interdomain routing protocol). Do protokołów klasy IGP należą RIP, RIP2, OSPF, OSPF2, IS- IS, NLSP, IGRP, EIGRP. Dwa ostatnie protokoły są utworzone przez firmę Cisco i są jej własnością. Ze względu na sposób działania protokoły routowania wewnętrznego dzielimy na protokoły typu: wektor odległości (DV, distance- vector): RIP, RIP2, IGRP, EIGRP stanu łącza (link- state): OSPF, OSPF2, IS- IS, NLSP (NetWare Link Services Protocol) Uwaga! W starszych opracowaniach firmy Cisco protokół EIGRP był określany jako protokół hybrydowy. Oprócz protokołów wewnętrznych są też tzw. zewnętrzne protokoły routowania (EGP exterior gateway protocols) - międzydomenowe protokoły routowania (interdomain routing protocols) używane między routerami działającymi w różnych systemach autonomicznych. Najważniejszym protokołem zewnętrznym jest BGP.
Przypomnienie oprócz protokołów routowania rozważa się protokoły routowalne, takie jak IP, IPX, Apple Talk. Routery mogą wyznaczać trasy dla różnych protokołów routowalnych, nie tylko IP. Każdy z protokołów routowania i każdy z protokołów routowalnych musi być w routerze skonfigurowany. Protokoły routowania typu wektor odległości (wektor- odległość) Distance vector wektor odległości. Protokoły wektora odległości są oparte na algorytmie Bellmana Forda obliczania najkrótszych ścieżek w grafie. Węzły grafu oznaczają routery, krawędzie odpowiadają połączeniom między routerami. Połączenia te mają różne koszty, co odpowiada różnym wagom krawędzi grafu. Generalnie w algorytmie Bellmana Forda zakłada się, że wagi krawędzi mogą być liczbami ujemnymi, jednak nie ma w grafie cyklu, w którym suma wag krawędzi jest ujemna. W protokołach routowania wagi nie mogą być ujemne, co powoduje, że można też wykorzystać np. algorytm Dijkstry (będzie rozważany dla protokołów stanu łącza). Poniższa procedura przedstawia przykładową implementację algorytmu Bellmana Forda bez sprawdzania cykli o ujemnej długości. Procedura wyznacza najkrótszą ścieżkę z wierzchołka źródłowego source do wszystkich wierzchołków w grafie. Wierzchołki są strukturami o polach distance oraz predecessor. Pole distance zawiera odległość wierzchołka od wierzchołka źródłowego. procedure BellmanFord(list vertices, list edges, vertex source) // This implementation takes in a graph, represented as lists of vertices // and edges, and modifies the vertices so that their distance and // predecessor attributes store the shortest paths. // Step 1: initialize graph for each vertex v in vertices: if v is source then v.distance := 0 else v.distance := infinity v.predecessor := null // Step 2: relax edges repeatedly for i from 1 to size(vertices)-1: // size(vertices) = number of vertices for each edge uv in edges: // uv is the edge from u to v u := uv.source v := uv.destination if u.distance + uv.weight < v.distance: v.distance := u.distance + uv.weight v.predecessor := u Dowód poprawności np. tu: http://wazniak.mimuw.edu.pl/index.php?title=zaawansowane_algorytmy_i_struktury_dany ch/wyk%c5%82ad_5. W protokołach typu wektor odległości realizowana jest rozproszona wersja algorytmu.
Analiza działania protokołów routowania typu wektor odległości. Przykłady. Problemy i metody przeciwdziałania. Rozważmy sieć z pięcioma węzłami routerami i sześcioma połączeniami: A 1 B 2 3 4 C D 6 E 5 Załóżmy, że do każdego routera jest podłączona jedna sieć lokalna, która ma pewien adres IPv4. Będziemy oznaczać te sieci literami A, B, C, D i E. Litera A na powyższym rysunku w jednym z węzłów oznacza, że do tego węzła jest podłączona bezpośrednio lokalna sieć oznaczona jako A. Dla wygody router ten też będziemy oznaczać A. Połączenia między routerami też mają przypisane adresy IP, ale dla uproszczenia tych adresów nie będziemy rozważać, odpowiednie sieci pominiemy w tablicach routowania routerów. Router oznaczony literą A ma więc trzy lub cztery interfejsy sieciowe jeden do sieci lokalnej A i dwa lub trzy łączące z innymi routerami. W tablicach routowania będziemy uwzględniać tylko sieci oznaczone literami. Na początku węzły znają trasy tylko do swoich sieci lokalnych, czyli podłączonych bezpośrednio do routera. Każdy router zna jedną sieć lokalną (oraz dwie lub trzy sieci łączące). Załóżmy, że koszt każdego połączenia z sąsiednim routerem wynosi jeden. Koszt sieci podłączonej bezpośrednio wynosi 0. Tablica routowania w węźle A: Z węzła A do A lokalne 0 Tablica routowania w węźle B: Z węzła B do B lokalne 0 Każdy węzeł przesyła co pewien czas wektor odległości do wszystkich swoich łączy, na których uruchomiono protokół routowania. Wektor odległości wysyłany przez router A
zawiera informację: do sieci A koszt 0 ; możemy to zapisać np. tak: A=0. Wektor odległości zawiera zatem informację o znanych trasach do pewnych sieci. Router A przesyła wektor odległości do węzłów B i D. Uwaga! W niektórych książkach można spotkać informację, że routery działające według protokołów wektora odległości, przesyłają między sobą tablice routowania. Jest to uproszczenie, ponieważ w rzeczywistości nie są przesyłane całe tablice routowania, jedynie wektory odległości do znanych sieci. Węzeł po otrzymaniu wektora odległości od sąsiada dodaje do kosztów zawartych tam tras koszt lokalnego połączenia (do sąsiada). Na przykład B po otrzymaniu wektora odległości od A dodaje 1 do kosztu trasy do A i ze względu na to, że nie posiada trasy do A dopisuje tę trasę do swojej tablicy routowania. Zatem teraz tablica routowania B wygląda tak: Z węzła B do B lokalne 0 A 1 1 Podobnie w węźle D tablica routowania będzie wyglądała tak: Z węzła D do D lokalne 0 A 3 1 Węzły B i D również przesyłają swoje tablice routowania do sąsiadów, B przesyła do A, E i C, natomiast D przesyła do A i E. Rozważmy teraz węzeł A. Otrzyma on wektory odległości od B i D, załóżmy, że najpierw otrzymał wektor odległości od B. Po otrzymaniu wektora odległości od B węzeł A modyfikuje go tak: B=1, A=2. Trasa do B jest dopisywana do tablicy routowania węzła A, natomiast trasa do A jest gorsza od trasy już przechowywanej w węźle A, zatem nie jest brana pod uwagę (gorsza oznacza, że ma wyższy koszt). Tablica routowania w węźle A wygląda teraz tak: Z węzła A do A lokalne 0 B 1 1 Po otrzymaniu wektor odległości od D tablica routowania w węźle A wygląda tak: Z węzła A do A lokalne 0 B 1 1 D 3 1 Załóżmy, że następnie węzeł C otrzymał wektor odległości od B na połączeniu numer 2 i zmodyfikował swoją tablicę routowania do:
Z węzła C do C lokalne 0 B 2 1 A 2 2 Wektor odległości z węzła B został też przesłany do E, zatem węzeł E zaktualizował swoją tablicę routowania tak: Z węzła E do E lokalne 0 B 4 1 A 4 2 Załóżmy, że następnie E dostał wektor odległości od D. Wektor ten zostaje zmodyfikowany o koszt połączenia lokalnego numer 6. Po modyfikacji wektor ten wygląda tak: D=1, A=2. Trasa do węzła D powinna być dopisana do tablicy routowania, natomiast koszt trasy do A jest taki sam jak koszt trasy już wpisanej do tablicy routowania w E. Załóżmy na razie, że w takim przypadku nowa trasa (do A) nie jest dopisywana do tablicy routowania. Zatem tablica routowania w E będzie wyglądała tak: Z węzła E do E lokalne 0 B 4 1 A 4 2 D 6 1 W węzłach A, C i E zostały wyznaczone nowe tablice routowania, zatem odpowiednie wektory odległości zostaną przesłane do sąsiadów: Z węzła A: A=0, B=1, D=1 Z węzła C: C=0, B=1, A=2 Z węzła E: E=0, B=1, A=2, D=1 do łączy o numerach 1 i 3 do łączy o numerach 2 i 5 do łączy o numerach 4, 5 i 6 Spowoduje to aktualizację tablic routowania w B, D i E: Z węzła B do B lokalne 0 A 1 1 D 1 2 C 2 1 E 4 1 Z węzła D do D lokalne 0 A 3 1
B 3 2 E 6 1 Z węzła E do E lokalne 0 B 4 1 A 4 2 D 6 1 C 5 1 Z kolei teraz w węzłach B, D i E wyznaczane są nowe wektory odległości i zostaną one przesłane do A, C i D, co z kolei spowoduje aktualizację tablic routowania w A, C i D. Z węzła A do A lokalne 0 B 1 1 D 3 1 C 1 2 E 1 2 Z węzła C do C lokalne 0 B 2 1 A 2 2 E 5 1 D 5 2 Z węzła D do D lokalne 0 A 3 1 B 3 2 E 6 1 C 6 2 W A, C i D wyznaczane są nowe wektory odległości i zostaną one przesłane do połączeń lokalnych, ale nie spowodują żadnych zmian w tablicach routowania. Od tej chwili aż do momentu wystąpienia jakichś zmian w konfiguracji sieci, przesyłane wektory odległości nie będą powodować żadnych zmian w tablicach routowania. Węzły wyznaczyły odległości i trasy do wszystkich sieci lokalnych. Czasem o stanie tym mówi się, że protokół routowania osiągnął zbieżność.
Co się stanie, gdy jedno z połączeń ulegnie awarii? Załóżmy, że awarii uległo połączenie numer 1 (między A i B). Załóżmy, że węzły potrafią sprzętowo wykryć awarię lokalnego połączenia. Załóżmy też, że uszkodzone połączenia mają koszt równy nieskończoności ( ). Zatem tablice routowania w A i B zostaną natychmiast zmodyfikowane tak: Z węzła A do A lokalne 0 B 1 D 3 1 C 1 E 1 Z węzła B do B lokalne 0 A 1 D 1 C 2 1 E 4 1 Uwaga. Protokoły typu wektor odległości mogą nie rozgłaszać informacji o sieci niedostępnej. Wówczas trasa do takiej sieci staje się niedostępna dla kolejnych routerów dopiero po tym, jak routery te nie otrzymają informacji o tej sieci przez pewną liczbę kolejnych rozgłoszeń (kilka). Przekazywanie informacji o trasach niedostępnych nazywane jest zatruwaniem tras (route poisoning). Oczywiście zatruwanie tras przyspiesza uzyskanie zbieżności. Termin zatruwanie tras zwykle można spotkać w kontekście jeszcze jednego mechanizmu, tzw. dzielonego horyzontu (będzie to wyjaśnione niżej). Węzły A i B wyślą (przy najbliższym przesyłaniu wynikającym z protokołu) nowe wektory odległości: Z węzła A: A=0, B=, D=1, C=, E= do łącza 3 Z węzła B: B=0, A=, D=, C=1, E=1 do łączy 2 i 4. Węzeł D po otrzymaniu wektora odległości od A i po zmodyfikowaniu tego wektora do: A=1, B=, D=2, C=, E= stwierdza, że przesłane trasy nie są lepsze od przechowywanych w tablicy routowania D. Jednak trasa do B wiedzie przez łącze 3, a z tego właśnie łącza nadeszła informacja o nieosiągalności B, zatem wpis dotyczący B powinien zostać zmodyfikowany. Nowa tablica routowania w węźle D będzie wyglądała tak: Z węzła D do D lokalne 0 A 3 1
B 3 E 6 1 C 6 2 Podobnie zmienią się tablice routowania w węzłach C i E: Z węzła C do C lokalne 0 B 2 1 A 2 E 5 1 D 5 2 Z węzła E do E lokalne 0 B 4 1 A 4 D 6 1 C 5 1 Węzły D, C i E wyślą nowe wektory odległości. Z węzła D: D=0, A=1, B=, E=1, C=2 do łączy 3 i 6 Z węzła C: C=0, B=1, A=, E=1, D=2 do łączy 2 i 5 Z węzła E: E=0, B=1, A=, D=1, C=1 do łączy 4, 5 i 6 Przesłane wektory odległości spowodują aktualizację tablic routowania w węzłach A, B, D i E: Z węzła A do A lokalne 0 B 1 D 3 1 C 3 3 E 3 2 Z węzła B do B lokalne 0 A 1 D 4 2 C 2 1 E 4 1 Z węzła D do D lokalne 0
A 3 1 B 6 2 E 6 1 C 6 2 Z węzła E do E lokalne 0 B 4 1 A 6 2 D 6 1 C 5 1 Po tych aktualizacjach zostaną przesłane nowe wektory odległości: Z węzła A: A=0, B=, D=1, C=3, E=2 do łącza 3 Z węzła B: B=0, A=, D=2, C=1, D=1 do łączy 2 i 4 Z węzła D: D=0, A=1, B=2, E=1, C=2 do łączy 3 i 6 Z węzła E: E=0, B=1, A=2, D=1, C=1 do łączy 4, 5 i 6 To z kolei spowoduje modyfikację tablic routowania w A, B i C: Z węzła A do A lokalne 0 B 3 3 D 3 1 C 3 3 E 3 2 Z węzła B do B lokalne 0 A 4 3 D 4 2 C 2 1 E 4 1 Z węzła C do C lokalne 0 B 2 1 A 5 3 E 5 1 D 5 2
Kolejne przesyłane wektory odległości nie spowodują żadnych zmian w tablicach routowania, zatem osiągnięta została zbieżność w nowej topologii połączeń. Wszystkie węzły są osiągalne z dowolnego węzła w sieci. Uwaga. Nie zawsze router jest w stanie wykryć uszkodzenie łącza. Ponadto uszkodzeniu może ulec nie tylko łącze, ale np. sąsiedni router (np. zawiedzie oprogramowanie routera). Dlatego w protokołach typu wektor odległości trasa jest zaznaczana jako niedostępna, gdy router nie dostanie o niej informacji od sąsiada przez kilka kolejnych rozgłoszeń. Np. w RIP ten czas wynosi 180 sekund, czyli sześć rozgłoszeń, gdyż rozgłoszenia wektorów odległości są wykonywane co 30 sekund. Trasa niedostępna nie jest jeszcze usuwana z tablicy routowania przez kilka rozgłoszeń, np. w RIP przez kolejne 90 sekund (3 rozgłoszenia). Powoduje to jeszcze większe opóźnienie w czasie uzyskania zbieżności. Pętle routowania (routing loops, bouncing effect) Załóżmy, że koszt połączenia numer 5 jest nie jeden, lecz dziesięć. W poniższej tabeli zamieszczone są trasy do C z każdego z węzłów: z węzła A do C 1 2 z węzła B do C 2 1 z węzła C do C lokalne 0 z węzła D do C 3 3 z węzła E do C 4 2 Prześledźmy, co się stanie po uszkodzeniu połączenia numer 2 (z B do C). Przez krótki czas (zanim B prześle nowy wektor odległości) trasy będą takie: z węzła A do C 1 2 z węzła B do C 2 z węzła C do C lokalne 0 z węzła D do C 3 3 z węzła E do C 4 2 Załóżmy, że zanim węzeł B zdążył wysłać nowy wektor odległości do A i E, otrzymał wektor odległości od A (A wysłał do B i D). W węźle D nic się nie zmieni, ale B po dodaniu jedynki (kosztu łącza) do kosztu trasy z A do C (koszt=2) otrzyma trasę przez A do C o koszcie równym 3. Koszt ten jest niższy od nieskończoności, zatem B zmienia swoją tablicę routowania i nowy wektor odległości zostanie przesłany do A i E. Ze względu na to, że wektor ten dotrze do A i E przez połączenia 1 i 4, które były normalnie używane jako trasy do C z A i E, w węzłach tych (tj. A i E) muszą się zmienić tablice routowania. Sytuacja jest więc następująca:
z węzła A do C 1 4 z węzła B do C 1 3 z węzła C do C lokalne 0 z węzła D do C 3 3 z węzła E do C 4 4 Teraz tablice routowania zawierają pętlę. Każdy datagram kierowany do C dotrze do B, a następnie będzie odbijany (bouncing effect) między B i A aż do wyzerowania pola TTL. Efekt ten zostanie zatrzymany dopiero po osiągnięciu nowego stanu zbieżności. Prześledźmy, co się będzie działo dalej w rozważanej sieci. Jeśli C ogłosi swój wektor odległości do E, E doda 10 do kosztu (10+0=10) i trasa nie zostanie uwzględniona w tablicy routowania E. Jeśli A i E prześlą swoje tablice routowania do D i B to sytuacja się zmieni: z węzła A do C 1 4 z węzła B do C 1 5 z węzła C do C lokalne 0 z węzła D do C 3 5 z węzła E do C 4 4 Po przesłaniu nowego wektora odległości z B do A trasa z A do C zwiększy koszt do 6. Po przesłaniu nowego wektora odległości z A do D i B sytuacja będzie taka: z węzła A do C 1 6 z węzła B do C 1 7 z węzła C do C lokalne 0 z węzła D do C 3 7 z węzła E do C 4 6 Znowu wektor odległości przesłany przez C do E jest w E ignorowany. Każda runda wymiany wektorów odległości zwiększa koszt trasy do C z węzłów A, B, D i E. Po następnej rundzie będziemy mieli: z węzła A do C 1 8 z węzła B do C 1 9 z węzła C do C lokalne 0 z węzła D do C 3 9 z węzła E do C 4 8 Po kolejnych rundach otrzymamy w pewnej chwili:
z węzła A do C 1 12 z węzła B do C 1 11 z węzła C do C lokalne 0 z węzła D do C 3 11 z węzła E do C 4 12 Teraz jeśli E otrzyma wektor odległości z C, zmieni tablicę routowania, co w końcu doprowadzi do sytuacji: z węzła A do C 1 12 z węzła B do C 4 11 z węzła C do C lokalne 0 z węzła D do C 6 11 z węzła E do C 5 10 Otrzymaliśmy zbieżność w nowej topologii, pętla routowania została usunięta. Trwało to jednak stosunkowo długo. W czasie, gdy istniała pętla, gubione były datagramy, ponadto krążenie datagramów może doprowadzić do przeciążenia sieci i datagramy mogą być gubione nawet nie z powodu wyzerowania TTL, co z kolei może doprowadzić do jeszcze większych opóźnień w wymianie wektorów odległości między routerami (jeśli datagramy z tymi wektorami będą gubione). Zliczanie do nieskończoności (counting to infinity) Załóżmy, że w rozważanej sieci jest uszkodzone połączenie numer 1 i uszkodzeniu uległo drugie połączenie numer 6. Teraz węzły A i D są odcięte od węzłów B, C i E. Rozważmy tylko węzły A i D. Tablica routowania w węźle D będzie taka: Z węzła D do D lokalne 0 A 3 1 B 6 E 6 C 6 W węźle A mamy: Z węzła A do A lokalne 0 B 3 3 D 3 1
C 3 3 E 3 2 Jeśli D wyśle swój wektor odległości najpierw (zanim zrobi to A), wówczas A natychmiast wykryje, że jedynym dostępnym węzłem jest D i została osiągnięta zbieżność. Jeśli jednak zdarzyłoby się, że najpierw wektor odległości zostanie przesłany z A do D: Z węzła A: A=0, B=3, D=1, C=3, E=2 do łącza 3 To spowoduje modyfikację tablicy routowania w D: Z węzła D do D lokalne 0 A 3 1 B 3 4 E 3 3 C 3 4 Pojawi się pętla routowania. Co więcej, za każdym kolejnym przesłaniem wektora odległości koszt połączeń będzie wzrastał o 2. To zjawisko nazywane jest zliczaniem do nieskończoności (counting to infinity). W protokołach typu wektor odległości ustalana jest pewna granica kosztu, powyżej której połączenie traktowane jest jako niedostępne. Np. w protokole RIP liczba 16 oznacza nieskończoność (miejsce docelowe niedostępne). Oczywiście w tracie tego zliczania do nieskończoności zawartość tablic routowania powoduje pętle. Dzielony horyzont (split horizon) Pętle routowania, efekt odbijania (bouncing effect), zliczanie do nieskończoności to niekorzystne zjawiska związane z routowaniem według protokołów typu wektor odległości. Aby zminimalizować te niekorzystne zjawiska stosowane są różne techniki, m.in. dzielony horyzont (split horizon) i natychmiastowe (wymuszane) aktualizacje (triggered updates). Idea dzielonego horyzontu opiera się na prostej obserwacji: jeśli węzeł A przekazuje datagramy do pewnego miejsca przeznaczenia X przez węzeł B, to nie ma sensu, aby B przekazywał datagramy do X przez A. Podobnie nie ma sensu przekazywanie informacji z A do B, że trasa do X wiedzie przez A. Zatem węzeł nie będzie przekazywał jednakowego wektora odległości do wszystkich łączy. Do łącza nie zostanie przekazana informacja o trasach wiodących przez to łącze. Taka technika spowoduje, że w rozważanej sieci z uszkodzonymi połączeniami numer 1 i 6 nie powstanie pętla routowania między A i D, gdyż A nie prześle do węzła D informacji o trasach z wykorzystaniem łącza numer 3.
Dzielony horyzont nie zawsze likwiduje pętle routowania. Przyjrzyjmy się naszej przykładowej sieci z uszkodzonymi połączeniami o numerach 1 i 6. Weźmy teraz pod uwagę routery B, C i E. Zaraz po uszkodzeniu połączenia między D i E sytuacja jest taka: z węzła B do D 4 2 z węzła C do D 5 2 z węzła E do D 6 E wysyła nowy wektor odległości do łączy 4 i 5. Załóżmy, że wektor ten dotarł do B, ale ze względu np. na błędy transmisji nie dotarł do C. Sytuacja jest teraz taka: z węzła B do D 4 z węzła C do D 5 2 z węzła E do D 6 Informacja z C o trasie do D jest oczywiście potem przesłana do B (do E nie jest przesyłana, bo działa dzielony horyzont), B aktualizuje swoja tablicę routowania: z węzła B do D 2 3 z węzła C do D 5 2 z węzła E do D 6 B przekazuje do węzła E informację o trasie do D. E aktualizuje swoją tablicę routowania i sytuacja jest taka: z węzła B do D 2 3 z węzła C do D 5 2 z węzła E do D 4 4 Oczywiście E wysyła do C informację o nowej trasie do D i C aktualizuje swoją tablicę routowania, zwiększając koszt trasy do węzła D do 5: z węzła B do D 2 3 z węzła C do D 5 5 z węzła E do D 4 4 Otrzymaliśmy znowu pętlę routowania i wystąpi efekt zliczania do nieskończoności (spowoduje on wolniejszą zbieżność).
Dzielony horyzont może wykorzystywać pewną wersję zatruwania zatruwania tras tzw. split horizon with poison reverse informacja odwrotna (reverse) jest przekazywana, jednak z metryką nieskończoną. Poison reverse updates jest tu odmianą zatruwania tras, ale tych normalnie nie rozgłaszanych w wyniku działania strategii split horizon. Technika ta może zapobiec większym pętlom rutowania. Natychmiastowe wymuszane aktualizacje (triggered updates) W przypadku zmiany metryki trasy musi nastąpić rozgłoszenie (bez względu na okres rozgłoszeń charakterystyczny dla danego protokołu). Powoduje to szybszą zbieżność i częściowo zapobiega pętlom routowania. Zegary hold- down (hold- down timers) Inny mechanizm stosowany w celu uniknięcia niekorzystnych zjawisk związanych z routowaniem typu wektor odległości to tzw. zegary hold- down. Router po otrzymaniu od sąsiada informacji o dezaktualizacji trasy włącza specjalny zegar (hold- down timer). Jeśli przed upływem czasu progowego nastąpi aktualizacja od tego samego sąsiada na trasę aktywną, to trasa jest zaznaczana jako aktywna. Jeśli przed upływem czasu progowego router dostanie od innego routera informację o trasie do rozważanego miejsca docelowego z metryką mniejszą bądź równą tej zdezaktualizowanej, wówczas następuje wpis zgłoszonej trasy. Jeśli przed upływem czasu progowego router dostanie od innego routera informację o trasie do rozważanego miejsca docelowego z metryką większą od tej zdezaktualizowanej, taka trasa nie jest brana pod uwagę. Protokół routowania RIP (RFC 1058) RIP jest protokołem typu wektor odległości. Metryką w RIP jest liczba skoków (hops) do celu (0 oznacza sieć dołączoną bezpośrednio, 1 oznacza, że po drodze do sieci docelowej jest jeden skok do następnego routera itd.). Administrator może skonfigurować inne wartości dla pewnych połączeń, tym samym może wprowadzić np. preferencje dla tras szybszych. Routery Cisco mają możliwość ustawienia automatycznego powiększania metryki o zadaną liczbę dla wszystkich tras, o których router dowiedział się z określonego interfejsu. Na podstawie informacji (wektorów odległości) otrzymanych od sąsiadów router aktualizuje swoją tablicę routowania. Przy najbliższym rozgłoszeniu przesyłany jest zaktualizowany wektor odległości. W typowy dla protokołów DV sposób informacja o dostępnych sieciach rozchodzi się po całej sieci. W protokole RIP metryka 16 oznacza umownie nieskończoność (miejsce niedostępne), zatem RIP nie jest dobrym protokołem w przypadku dużych sieci. Trasa o metryce 16 jest traktowana jak trasa niedostępna. W RIP można ustawić trasę domyślną (adres 0.0.0.0). W wersji RIP obsługiwanej przez routery Cisco można przechowywać więcej niż jedną trasę o takiej samej metryce. Można włączyć równoważenie obciążeń (load balancing) na dwa sposoby:
Process switching (packet- by- packet load balancing), kosztowny i dlatego nie polecany, każdy pakiet jest kierowany osobno, dla każdego jest przeglądana tablica routowania. Fast switching (destination- by- destination), tylko dla pierwszego pakietu z pewnego miejsca źródłowego do pewnego miejsca docelowego przeszukiwana jest tablica routowania. Wyznaczona trasa jest zapisywana w pamięci podręcznej (cache) i kolejne pakiety wędrują tą samą ścieżką. W protokole RIP wykorzystywane są następujące mechanizmy typowe dla protokołów wektor odległości: Split horizon (+ with poison reverse) Holddown counters Triggered updates W protokole RIP są zaimplementowane cztery zegary, liczniki (timers, counters): Update timer (standardowo ustawiony na 30 sekund) po przesłaniu wektora odległości (routing update) zegar jest zerowany. Po osiągnięciu 30 wysyłany jest następny wektor. Invalid timer (standardowo ustawiony na 180 sekund) za każdym razem jak router dostaje uaktualnienie pewnej trasy (tzn. informację o niej od innego routera) zegar ten dla trasy jest zerowany. Po osiągnięciu wartości progowej (180s.) trasa jest zaznaczana jako niepoprawna (invalid), ale pakiety jeszcze są kierowane tą trasą. Hold- down timer (standardowo ustawiany na 180s.) po przekroczeniu wartości progowej przez invalid timer trasa jest ustawiana w stan hold- down. Trasa jest ustawiana w stan hold- down również gdy router dostanie informację o tym, że sieć jest nieosiągalna (i nie ma innej, osiągalnej trasy). Flush- timer (standardowo ustawiony na 240s.) zegar dla trasy jest zerowany po otrzymaniu informacji o trasie. Po osiągnięciu czasu progowego trasa jest usuwana nawet, jeśli trasa jest jeszcze w stanie hold- down. W protokole RIP przewidziano możliwość odpytywania routera o cały wektor odległości lub o trasy do pewnych miejsc docelowych takie możliwości są wykorzystywane prze starcie oraz na ogół w celach diagnostycznych. Format komunikatu RIP Komunikaty RIP przesyłane są w datagramach UDP: Nagłówek IP (20 bajtów), nagłówek UDP (8 bajtów), Komunikat RIP: polecenie (1-6) bity 0-7, wersja (1) bity 8-15, musi być zero bity 16-31, rodzina adresów (2) bity 32-47, musi być zero bity 48-63, adres IP kolejne 32 bity, musi być zero kolejne 32 bity, musi być zero kolejne 32 bity,
metryka (1-16) kolejne 32 bity,... (do 24 tras o formacie takim jak poprzednie 20 bajtów). W komunikatach RIP przekazywane są adresy do hostów, i sieci z wykorzystaniem klas. Zaletą protokołu RIP jest jego prostota (zatem procesor nie jest nadmiernie obciążony aktualizacją tablicy routowania i innymi działaniami) i łatwość konfiguracji. Wadą jest zbyt wolne rozprzestrzenianie się informacji o zmianach w topologii sieci (np. po zerwaniu pewnego połączenia). Mówi się o wolnej zbieżności protokołu RIP. Inną wadą jest przesyłanie dużych porcji informacji w komunikatach RIP (całe wektory odległości), co obciąża sieć. Kolejną wadą RIP jest to, że nie daje możliwości przesyłania masek. RIP w wersji 1 jest protokołem routowania klasowego. W przypadku otrzymania informacji o podsieci pewnej sieci klasowej, przyjmowana jest maska taka, jaka jest ustawiona na interfejsie, do którego dotarł wektor odległości z tą informacją. Na granicach klas jednak routery RIP wykonują automatyczną sumaryzację, co przy niepoprawnych konfiguracjach może prowadzić do błędów w routowaniu (przykład na tablicy). Przypomnienie: zbieżność oznacza stan, w którym wszystkie routery mają taki sam, prawidłowy obraz sieci (na pewnym obszarze). Przed osiągnięciem zbieżności, w trakcie rozprzestrzeniania informacji o zmianach w sieci może występować niekonsekwentne routowanie czy pętle. RIP 2 (RFC1723) RIP2 przekazuje maski podsieci, można stosować sieci bezklasowe (CIDR Classless Interdomain Routing) i podsieci o zmiennym rozmiarze (VLSM Variable Length Subnet Mask). Umożliwia prostą autentykację (przez hasła). Przekazuje adresy następnego skoku w komunikatach. Część wad RIP pozostała: 16 jako metryka oznaczająca nieskończoność, brak alternatywnych tras. Środowiska z wieloma protokołami routowania. Odległości administracyjne. W środowisku współdziałania wielu protokołów routowania, dla tras w zależności od tego jakie jest źródło, z którego router dowiedział się o trasie, ustawiana jest tzw. odległość administracyjna (NIE metryka) administrative distance. Dla protokołu RIP odległość wynosi 120. Odległość jest używana tylko wewnętrznie przez router. Router wybiera trasy o najmniejszej odległości. Dla wpisu statycznego przyjmuje się odległość administracyjną równą 1, dla sieci dołączonej bezpośrednio odległość jest równa zero. Standardowe odległości dla tras: Źródło trasy Connected interface Odległość (administrative distance) 0
Static route Summary EIGRP External BGP Internal EIGRP IGRP OSPF IS- IS RIP EGP Internal BGP Unknown 1 5 20 90 100 110 115 120 140 200 255 Na routerach można również włączyć redystrybucję tras między protokołami routowania według różnych zasad, z odpowiednim przeliczaniem metryk. IGRP IGRP jest protokołem typu wektor odległości. IGRP działa wewnątrz systemu autonomicznego i przy konfiguracji protokołu należy podać numer tego systemu. IGRP został utworzony przez firmę Cisco jako rozwiązanie pewnych problemów związanych ze stosowaniem RIP głównie chodziło o rozróżnienie między technologiami sieciowymi o różnych przepustowościach. IGRP nie jest już wspierany przez firmę Cisco, jest wycofany. Zastępuje go protokół EIGRP. Metryka w IGRP jest tworzona na podstawie wartości metryk cząstkowych oraz zmiennych określających wagę każdej użytej metryki. Używane są następujące metryki cząstkowe: Szerokość pasma (bandwidth); oznacza liczbę bitów, jakie może transmitować w jednostce czasu dana technologia. Opóźnienie (delay) czas wędrówki pakietu od źródła do celu; wartości od 1 do 2 24, przy czym 1 oznacza 10 mikrosekund. Obciążenie (load); wartość od 1 do 255. 1 oznacza sieć najmniej obciążoną, 255 najbardziej obciążoną. Niezawodność (reliability); wartość od 1 do 255. Wartość liczona jest jako swoisty % pakietów, które dotarły do następnego routera, przy czym liczba 255 oznacza 100%. Ponadto w wektorach odległości przesyłane są również wartości MTU (Maximum Transfer Unit) oraz liczba skoków, jednak wartości te nie są wykorzystywane do obliczenia kosztu trasy. Liczba skoków jest używana jako kryterium odrzucania tras podejrzanych o zapętlenie (zbyt długich). Maksymalna liczba skoków w IGRP wynosi 255, ale standardowo jest ustawiana na 100 (można ją zmieniać). Standardowo do wyliczenia kosztu trasy (metryki całkowitej) wybierane są tylko szerokość pasma i opóźnienie.
Wybrane typowe wartości metryk dla opóźnienia i szerokości pasma: Delay Bandwidth --------------- ------------------- Satellite 200,000 (2 sec) 20 (500 Mbit) Ethernet 100 (1 ms) 1,000 1.544 Mbit 2000 (20 ms) 6,476 64 Kbit 2000 156,250 56 Kbit 2000 178,571 10 Kbit 2000 1,000,000 1 Kbit 2000 10,000,000 Sposób wyliczania metryki końcowej w Cisco: metric = [K1*bandwidth + (K2*bandwidth)/(256 - load) + K3*delay] * [K5/(reliability + K4)] Jeśli K5==0, czynnik związany z niezawodnością (reliability) nie jest wykorzystywany. Domyślnie przyjmowane są następujące wartości: K1 == K3 == 1, K2 == K4 == K5 == 0. Trasa z najmniejszą wartością końcowej metryki jest wybierana jako najlepsza. W IGRP przechowywanych jest kilka optymalnych tras do pewnego miejsca docelowego. Ponadto mogą być przechowywane informacje o trasach nieoptymalnych, których metryka nie różni się więcej niż zadana wielkość (można ją zmienić) od metryki optymalnej. W IGRP jest przeprowadzane równoważenie obciążenia (load balancing). Przez wszystkie trasy wiodące do pewnego celu są przesyłane datagramy, przy czym liczba datagramów przesyłanych przez pewną trasę jest odwrotnie proporcjonalna do metryki końcowej tej trasy). W IGRP są wykorzystywane trzy typy tras: wewnętrzne (do podsieci dołączonych bezpośrednio do routera) systemowe (do sieci w ramach systemu autonomicznego) zewnętrzne (do innych systemów autonomicznych) W IGRP NIE ma trasy domyślnej 0.0.0.0. Zamiast tego pewne trasy mogą być zaznaczane jako zewnętrzne. Trasa zewnętrzna prowadzi przez tzw. router of last resort (router, który jest ostatnią deską ratunku ) i jest wybierana, jeśli nie znaleziono innej. Zastosowane mechanizmy zapobiegania niekorzystnym zjawiskom to: holddown- timers (standardowo 3* update timer + 10s.), split horizon with poison reverse, natychmiastowe aktualizacje. Wektory odległości są rozgłaszane co 90 sekund (update timer). Trasa jest uważana za niepoprawną, jeśli nie nadeszły z niej trzy kolejne rozgłoszenia (invalid timer - 270 sekund). Hold- down timer 280s. Flush timer 630 s. Pierwsza wersja IGRP nie obsługuje routowania bezklasowego ani VLMS.