SK Moduł 10: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
Linia 1: | Linia 1: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd1.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd1.png|thumb|500px]] | ||
|valign="top"| | |valign="top"| | ||
|} | |} | ||
Linia 6: | Linia 6: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd2.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd2.png|thumb|500px]] | ||
|valign="top"|W module tym zostaną omówione podstawowe informacje na temat routingu. | |valign="top"|W module tym zostaną omówione podstawowe informacje na temat routingu. | ||
Routing jest spisanym zestawem sposobów jak przejść (przesłać pakiety) z jednej sieci do drugiej. Jest to jedno z podstawowych własności routerów umożliwiającym przesyłanie danych w Internecie. | Routing jest spisanym zestawem sposobów jak przejść (przesłać pakiety) z jednej sieci do drugiej. Jest to jedno z podstawowych własności routerów umożliwiającym przesyłanie danych w Internecie. | ||
Linia 20: | Linia 20: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd3.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd3.png|thumb|500px]] | ||
|valign="top"|Router jest specjalistycznym komputerem, którego podstawowym zadaniem jest właściwe przesyłanie pakietów, które przychodzą na jeden z jego interfejsów na inny. Dzięki temu możliwa jest niezawodna komunikacja pomiędzy poszczególnymi sieciami komputerowymi. | |valign="top"|Router jest specjalistycznym komputerem, którego podstawowym zadaniem jest właściwe przesyłanie pakietów, które przychodzą na jeden z jego interfejsów na inny. Dzięki temu możliwa jest niezawodna komunikacja pomiędzy poszczególnymi sieciami komputerowymi. | ||
Linia 34: | Linia 34: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd4.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd4.png|thumb|500px]] | ||
|valign="top"|Tak jak już zostało to wcześniej wspomniane router jest specjalistycznym komputerem, którego zadaniem jest przesyłanie pakietów bez wnikania w ich zawartość (przy pominięciu funkcji ściany ogniowej). | |valign="top"|Tak jak już zostało to wcześniej wspomniane router jest specjalistycznym komputerem, którego zadaniem jest przesyłanie pakietów bez wnikania w ich zawartość (przy pominięciu funkcji ściany ogniowej). | ||
Linia 50: | Linia 50: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd5.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd5.png|thumb|500px]] | ||
|valign="top"|Router jako urządzenie umożliwiające właściwe przekierowanie pakietów na poszczególne interfejsy do urządzeń sąsiadujących potrzebuje właściwej informacji, która musi być zawarta w dostarczanych do niego pakietach. | |valign="top"|Router jako urządzenie umożliwiające właściwe przekierowanie pakietów na poszczególne interfejsy do urządzeń sąsiadujących potrzebuje właściwej informacji, która musi być zawarta w dostarczanych do niego pakietach. | ||
Linia 60: | Linia 60: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd6.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd6.png|thumb|500px]] | ||
|valign="top"|Protokół IP jest przykładem protokołu routowalnego. Szczegółowo został omówiony w poprzednich modułach. | |valign="top"|Protokół IP jest przykładem protokołu routowalnego. Szczegółowo został omówiony w poprzednich modułach. | ||
Protokół ten jest bezpołączeniowy, co oznacza, że do przesłania danych nie potrzebne jest zestawienie połączenie pomiędzy nadawcą i odbiorcą. Jest to protokół, który został opracowany do działania również w sytuacjach ekstremalnych, np. w czasie wojny. W związku z tym, używa wszelkich dostępnych ścieżek, aby dostarczyć pakiety do celu. | Protokół ten jest bezpołączeniowy, co oznacza, że do przesłania danych nie potrzebne jest zestawienie połączenie pomiędzy nadawcą i odbiorcą. Jest to protokół, który został opracowany do działania również w sytuacjach ekstremalnych, np. w czasie wojny. W związku z tym, używa wszelkich dostępnych ścieżek, aby dostarczyć pakiety do celu. | ||
Linia 69: | Linia 69: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd7.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd7.png|thumb|500px]] | ||
|valign="top"|W zależności od sposobu zdobywania informacji na temat dróg przesyłania poszczególnych pakietów dzieli się routing na statyczny i dynamiczny. | |valign="top"|W zależności od sposobu zdobywania informacji na temat dróg przesyłania poszczególnych pakietów dzieli się routing na statyczny i dynamiczny. | ||
Linia 81: | Linia 81: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd8.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd8.png|thumb|500px]] | ||
|valign="top"|Tablice routingu są tworzone w celu wyboru optymalnej ścieżki przesyłania pakietów. W przypadku routingu statycznego wpisów do tych tablic dokonuje administrator. W przypadku routngu dynamicznego tworzeniem tablic zajmują się protokoły routingu, na podstawie informacji od innych routerów. | |valign="top"|Tablice routingu są tworzone w celu wyboru optymalnej ścieżki przesyłania pakietów. W przypadku routingu statycznego wpisów do tych tablic dokonuje administrator. W przypadku routngu dynamicznego tworzeniem tablic zajmują się protokoły routingu, na podstawie informacji od innych routerów. | ||
Linia 92: | Linia 92: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd9.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd9.png|thumb|500px]] | ||
|valign="top"|Wśród danych, które mogą występować w tablicach routingu są następujące elementy: | |valign="top"|Wśród danych, które mogą występować w tablicach routingu są następujące elementy: | ||
typ protokołu - wpis, który z protokołów routingu dostarczył informacji na temat danej trasy | typ protokołu - wpis, który z protokołów routingu dostarczył informacji na temat danej trasy | ||
Linia 102: | Linia 102: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd10.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd10.png|thumb|500px]] | ||
|valign="top"|Na slajdzie została pokazana przykładowa tablica routingu uzyskana na stacji roboczej pod kontrolą systemu operacyjnego UNIX, za pomocą polecenia netstat -rn. | |valign="top"|Na slajdzie została pokazana przykładowa tablica routingu uzyskana na stacji roboczej pod kontrolą systemu operacyjnego UNIX, za pomocą polecenia netstat -rn. | ||
Linia 117: | Linia 117: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd11.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd11.png|thumb|500px]] | ||
|valign="top"|Określenie routing statyczny odnosi się do przypadku, gdy informacje na temat topologii sieci i tras przesyłania pakietów są wpisane na stałe przez administratora systemu. | |valign="top"|Określenie routing statyczny odnosi się do przypadku, gdy informacje na temat topologii sieci i tras przesyłania pakietów są wpisane na stałe przez administratora systemu. | ||
Linia 132: | Linia 132: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd12.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd12.png|thumb|500px]] | ||
|valign="top"|Tak jak już zostało to podane wcześniej często zachodzi potrzeba wpisania tzw. tras domyślnych (ang. deafault route). Są to wpisy w tabeli routingu, które umożliwiają określenie ścieżki przesyłania pakietów, dla których nie zadeklarowano lub nie została określona w sposób dynamiczny ścieżka. W ten sposób wszystkie te pakiety zostaną automatycznie skierowane do określonego routera. | |valign="top"|Tak jak już zostało to podane wcześniej często zachodzi potrzeba wpisania tzw. tras domyślnych (ang. deafault route). Są to wpisy w tabeli routingu, które umożliwiają określenie ścieżki przesyłania pakietów, dla których nie zadeklarowano lub nie została określona w sposób dynamiczny ścieżka. W ten sposób wszystkie te pakiety zostaną automatycznie skierowane do określonego routera. | ||
Linia 140: | Linia 140: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd13.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd13.png|thumb|500px]] | ||
|valign="top"|Jednym z kryteriów podziału protokołów routingu jest zasięg ich działania. Systemy, które działają w ramach jednej organizacji określane są jako systemy autonomiczne (ang. Autonomous Systems). Systemom takim nadawane są unikalne numery systemów autonomicznych. Systemy autonomiczne uzyskują numery IP z puli niezależnej od dostawców Internetu PI (ang. Provider Independent). Same numery systemów zawierają się w przedziale od 1 do 65535. Numery od 65412 do 65535 są wyłączone z użytkowania w sieciach publicznych. Są to numery prywatne. Przydziałem numerów publicznych zajmuje się międzynarodowa organizacja ICANN (ang. Internet Corporation for Assigned Names and Numbers). Lokalnie nadawaniem tych numerów zajmują się regionalne przedstawicielstwa tej organizacji. | |valign="top"|Jednym z kryteriów podziału protokołów routingu jest zasięg ich działania. Systemy, które działają w ramach jednej organizacji określane są jako systemy autonomiczne (ang. Autonomous Systems). Systemom takim nadawane są unikalne numery systemów autonomicznych. Systemy autonomiczne uzyskują numery IP z puli niezależnej od dostawców Internetu PI (ang. Provider Independent). Same numery systemów zawierają się w przedziale od 1 do 65535. Numery od 65412 do 65535 są wyłączone z użytkowania w sieciach publicznych. Są to numery prywatne. Przydziałem numerów publicznych zajmuje się międzynarodowa organizacja ICANN (ang. Internet Corporation for Assigned Names and Numbers). Lokalnie nadawaniem tych numerów zajmują się regionalne przedstawicielstwa tej organizacji. | ||
Linia 150: | Linia 150: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd14.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd14.png|thumb|500px]] | ||
|valign="top"|Podział ze względu na sposób wyznaczania trasy wynika z odmiennego podejścia do tworzenia informacji na temat routingu. | |valign="top"|Podział ze względu na sposób wyznaczania trasy wynika z odmiennego podejścia do tworzenia informacji na temat routingu. | ||
Linia 160: | Linia 160: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd15.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd15.png|thumb|500px]] | ||
|valign="top"|Przykładami używanych protokołów routingu są: | |valign="top"|Przykładami używanych protokołów routingu są: | ||
RIP (ang. Routing Information Protocol) w wersji 1 i 2. | RIP (ang. Routing Information Protocol) w wersji 1 i 2. | ||
Linia 174: | Linia 174: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd16.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd16.png|thumb|500px]] | ||
|valign="top"|Protokoły routingu były oraz są projektowane z myślą o zapewnieniu skutecznego i szybkiego rouingu. Istnieją pewne ogólne cechy, których część lub wszystkie każdy z zaimplementowanych protokołów powinien spełniać: | |valign="top"|Protokoły routingu były oraz są projektowane z myślą o zapewnieniu skutecznego i szybkiego rouingu. Istnieją pewne ogólne cechy, których część lub wszystkie każdy z zaimplementowanych protokołów powinien spełniać: | ||
optymalizacja - pod tym wymaganiem kryje się zdolność algorytmu do wyboru ścieżek o najlepszych metrykach. | optymalizacja - pod tym wymaganiem kryje się zdolność algorytmu do wyboru ścieżek o najlepszych metrykach. | ||
Linia 185: | Linia 185: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd17.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd17.png|thumb|500px]] | ||
|valign="top"|Zadaniem protokołu routingu jest wybór optymalnej trasy dla przesyłanych pakietów. Pakiety mogą być wysłane krótszą trasą (przez mniejszą liczbę routerów) lub też trasą dłuższą. Optymalność obu tych tras może być wyznaczana na podstawie kilku cech, tak jak to zostało pokazane na rys. | |valign="top"|Zadaniem protokołu routingu jest wybór optymalnej trasy dla przesyłanych pakietów. Pakiety mogą być wysłane krótszą trasą (przez mniejszą liczbę routerów) lub też trasą dłuższą. Optymalność obu tych tras może być wyznaczana na podstawie kilku cech, tak jak to zostało pokazane na rys. | ||
|} | |} | ||
Linia 191: | Linia 191: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd18.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd18.png|thumb|500px]] | ||
|valign="top"|Do porównania kilku różnych alternatywnych tras przesyłania pakietów potrzebna jest jakaś miara. Podobnie jak w przypadku porównywania cech różnych obiektów, dystansu pomiędzy miastami, podobieństwa twarzy, itd. w przypadku określania optymalności danej trasy należy posłużyć się jakimiś wartościami poprzez zdefiniowanie metryki routingu. Różne protokoły routingu mogą wykorzystywać odrębne wartości. W skład wartości, które mogą być wykorzystywane przy definiowaniu metryki mogą wchodzić następujące parametry: | |valign="top"|Do porównania kilku różnych alternatywnych tras przesyłania pakietów potrzebna jest jakaś miara. Podobnie jak w przypadku porównywania cech różnych obiektów, dystansu pomiędzy miastami, podobieństwa twarzy, itd. w przypadku określania optymalności danej trasy należy posłużyć się jakimiś wartościami poprzez zdefiniowanie metryki routingu. Różne protokoły routingu mogą wykorzystywać odrębne wartości. W skład wartości, które mogą być wykorzystywane przy definiowaniu metryki mogą wchodzić następujące parametry: | ||
szerokość pasma - zwykle im szybsze łącze, tym bardziej preferowane, np. łącze 1Gb/s będzie bardziej preferowane niż łącze modemowe o prędkości 56kb/s | szerokość pasma - zwykle im szybsze łącze, tym bardziej preferowane, np. łącze 1Gb/s będzie bardziej preferowane niż łącze modemowe o prędkości 56kb/s | ||
Linia 206: | Linia 206: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd19.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd19.png|thumb|500px]] | ||
|valign="top"|Protokół RIPv1 został zaprojektowany jako protokół typu IGP wykorzystywany w ramach jednego systemu autonomicznego (AS). Standard ten został opisany w dokumencie RFC 1058. Protokół ten jest typu wektor odległości (ang. distance vector) i został zaprojektowany z myślą o małych sieciach o nieskomplikowanej topologii. | |valign="top"|Protokół RIPv1 został zaprojektowany jako protokół typu IGP wykorzystywany w ramach jednego systemu autonomicznego (AS). Standard ten został opisany w dokumencie RFC 1058. Protokół ten jest typu wektor odległości (ang. distance vector) i został zaprojektowany z myślą o małych sieciach o nieskomplikowanej topologii. | ||
Protokół ten obsługuje tylko adresację z podziałem na klasy, stąd nie nadaje się do obsługi sieci z zastosowaną adresacją VLSM. | Protokół ten obsługuje tylko adresację z podziałem na klasy, stąd nie nadaje się do obsługi sieci z zastosowaną adresacją VLSM. | ||
Linia 219: | Linia 219: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd20.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd20.png|thumb|500px]] | ||
|valign="top"|Informacje przenoszone przez ten protokół wysyłane są na adres rozgłoszeniowy. Sam pakiet przedstawiony na rysunku zawiera następujące pola: | |valign="top"|Informacje przenoszone przez ten protokół wysyłane są na adres rozgłoszeniowy. Sam pakiet przedstawiony na rysunku zawiera następujące pola: | ||
command - (1B) pole określające funkcje pakietu. Pole to może zawierać następujące wartości: | command - (1B) pole określające funkcje pakietu. Pole to może zawierać następujące wartości: | ||
Linia 235: | Linia 235: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd21.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd21.png|thumb|500px]] | ||
|valign="top"|Format RIPv2 został opracowany na początku lat 90-tych XX w jako modyfikacja szeroko stosowanego protokołu RIPv1. Tak jak zostało to podane na wcześniejszych slajdach wersja 1 protokołu posiadała kilka wad, które ograniczały jego zastosowanie. Poprawiona wersja protokołu usuwa te ograniczenia. | |valign="top"|Format RIPv2 został opracowany na początku lat 90-tych XX w jako modyfikacja szeroko stosowanego protokołu RIPv1. Tak jak zostało to podane na wcześniejszych slajdach wersja 1 protokołu posiadała kilka wad, które ograniczały jego zastosowanie. Poprawiona wersja protokołu usuwa te ograniczenia. | ||
Specyfikacja protokołu w wersji 2 została podana w dokumencie RFC 1723. | Specyfikacja protokołu w wersji 2 została podana w dokumencie RFC 1723. | ||
Linia 250: | Linia 250: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd22.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd22.png|thumb|500px]] | ||
|valign="top"|Jedną z dosyć istotnych niedogodności wersji 1 protokołu był brak możliwości obsługi sieci z adresacją bezklasową. W obliczu wyczerpujących się adresów IPv4 jest to dosyć duże ograniczenie. Stąd poprawienie tej niedoskonałości było istotne. | |valign="top"|Jedną z dosyć istotnych niedogodności wersji 1 protokołu był brak możliwości obsługi sieci z adresacją bezklasową. W obliczu wyczerpujących się adresów IPv4 jest to dosyć duże ograniczenie. Stąd poprawienie tej niedoskonałości było istotne. | ||
Linia 262: | Linia 262: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd23.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd23.png|thumb|500px]] | ||
|valign="top"|Wygląd pakietu dla protokołu RIPv2 został przedstawiony na rysunku. Poszczególne pola mają następujące znaczenie: | |valign="top"|Wygląd pakietu dla protokołu RIPv2 został przedstawiony na rysunku. Poszczególne pola mają następujące znaczenie: | ||
command - (1B) pole komendy | command - (1B) pole komendy | ||
Linia 278: | Linia 278: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd24.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd24.png|thumb|500px]] | ||
|valign="top"|Jedną z cech odróżniających wersję 2 od wersji 1 protokołu RIP jest możliwość autoryzacji, która została wprowadzona do wersji 2. Uzyskuje się ją dzięki zapisaniu w polu AFI wartości 0xFFFF. Wtedy oktety 7i 8 pakietu zawierają informację na temat typu autentykacji. Zaś w dwubajtowym polu authentication może być zawarte hasło pisane jawnym tekstem (nie jest to wystarczająca ochrona). Dlatego zaleca się stosowanie szyfrowania metodą Message-Digest 5 (MD5). | |valign="top"|Jedną z cech odróżniających wersję 2 od wersji 1 protokołu RIP jest możliwość autoryzacji, która została wprowadzona do wersji 2. Uzyskuje się ją dzięki zapisaniu w polu AFI wartości 0xFFFF. Wtedy oktety 7i 8 pakietu zawierają informację na temat typu autentykacji. Zaś w dwubajtowym polu authentication może być zawarte hasło pisane jawnym tekstem (nie jest to wystarczająca ochrona). Dlatego zaleca się stosowanie szyfrowania metodą Message-Digest 5 (MD5). | ||
Linia 286: | Linia 286: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd25.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd25.png|thumb|500px]] | ||
|valign="top"|W przypadku występowania alternatywnych tras może dojść do zapętlenia tras routingu objawiającego się nieprzesyłaniem pakietów. Aby zapobiec temu negatywnemu zjawisku stosuje się różne metody niwelujące takie zdarzenia. Problem ten dotyczy szczególnie protokołu RIP. | |valign="top"|W przypadku występowania alternatywnych tras może dojść do zapętlenia tras routingu objawiającego się nieprzesyłaniem pakietów. Aby zapobiec temu negatywnemu zjawisku stosuje się różne metody niwelujące takie zdarzenia. Problem ten dotyczy szczególnie protokołu RIP. | ||
Jedną z nich jest metoda podzielonego horyzontu (ang. split horizon). Metoda ta nie pozwala routerowi, który wysłał informację o danej sieci na przyjmowanie informacji o tej sieci od innych routerów. | Jedną z nich jest metoda podzielonego horyzontu (ang. split horizon). Metoda ta nie pozwala routerowi, który wysłał informację o danej sieci na przyjmowanie informacji o tej sieci od innych routerów. | ||
Linia 295: | Linia 295: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd26.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd26.png|thumb|500px]] | ||
|valign="top"|Protokół OSPF (ang. Open Shortest Path First) jest protokołem typu stanu łącza (link-state). Został on zaprojektowany przez Internet Engineering Task Force w 1988 roku. Protokół ten został opracowany na przełomie lat 80-tych i 90-tych XXw. jako protokół otwarty niezależny od producenta. Jednak najszerzej stosowana specyfikacja tego protokołu została zdefiniowana w dokumencie RFC 2178 dopiero pod koniec lat 90-tych XXw. Specyfikacja ta pozwoliła na szerokie wykorzystanie tego protokołu. | |valign="top"|Protokół OSPF (ang. Open Shortest Path First) jest protokołem typu stanu łącza (link-state). Został on zaprojektowany przez Internet Engineering Task Force w 1988 roku. Protokół ten został opracowany na przełomie lat 80-tych i 90-tych XXw. jako protokół otwarty niezależny od producenta. Jednak najszerzej stosowana specyfikacja tego protokołu została zdefiniowana w dokumencie RFC 2178 dopiero pod koniec lat 90-tych XXw. Specyfikacja ta pozwoliła na szerokie wykorzystanie tego protokołu. | ||
Linia 303: | Linia 303: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd27.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd27.png|thumb|500px]] | ||
|valign="top"|W związku z tym, że protokół OSPF pozwala na podzielenie obsługiwanej domeny na obszary w polu nagłówka pojawia się informacja o identyfikatorze obszaru do jakiego został przypisany router. | |valign="top"|W związku z tym, że protokół OSPF pozwala na podzielenie obsługiwanej domeny na obszary w polu nagłówka pojawia się informacja o identyfikatorze obszaru do jakiego został przypisany router. | ||
Linia 321: | Linia 321: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd28.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd28.png|thumb|500px]] | ||
|valign="top"|Gdy w polu „Typ” nagłówka pakietu OSPF wpisana jest wartość 1, to jest to informacja, że będzie przesyłany pakiet „Hello”. | |valign="top"|Gdy w polu „Typ” nagłówka pakietu OSPF wpisana jest wartość 1, to jest to informacja, że będzie przesyłany pakiet „Hello”. | ||
Pakiet ten zawiera wszelkie informacje niezbędne do przeprowadzenia procesu uzgadniania pomiędzy routerami. | Pakiet ten zawiera wszelkie informacje niezbędne do przeprowadzenia procesu uzgadniania pomiędzy routerami. | ||
Linia 328: | Linia 328: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd29.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd29.png|thumb|500px]] | ||
|valign="top"|Innym przykładem protokołu routingu jest EIGRP (ang. Enhanced Interior Gateway Routing Protocol). | |valign="top"|Innym przykładem protokołu routingu jest EIGRP (ang. Enhanced Interior Gateway Routing Protocol). | ||
Protokół ten został wprowadzony w 1994 r przez firmę Cisco. Jest on następcą protokołu IGRP, który działał w oparciu o wektor odległości. Ze względu na fakt, że protokół EIGRP ustanawia relacje z sąsiednimi urządzeniami budując w ten sposób spójną topologię sieci protokół ten posiada również cechy typowe dla protokołów typu stan łącza. | Protokół ten został wprowadzony w 1994 r przez firmę Cisco. Jest on następcą protokołu IGRP, który działał w oparciu o wektor odległości. Ze względu na fakt, że protokół EIGRP ustanawia relacje z sąsiednimi urządzeniami budując w ten sposób spójną topologię sieci protokół ten posiada również cechy typowe dla protokołów typu stan łącza. | ||
Linia 335: | Linia 335: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd30.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd30.png|thumb|500px]] | ||
|valign="top"|Protokół BGP (ang. Border Gateway Protocol) jest protokołem wykorzystywanym do wymiany informacji pomiędzy różnymi systemami autonomicznymi (AS). | |valign="top"|Protokół BGP (ang. Border Gateway Protocol) jest protokołem wykorzystywanym do wymiany informacji pomiędzy różnymi systemami autonomicznymi (AS). | ||
Jego specyfikacje znajdują się dokumentach RFC: | Jego specyfikacje znajdują się dokumentach RFC: | ||
Linia 348: | Linia 348: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd31.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd31.png|thumb|500px]] | ||
|valign="top"|Protokół BGP uruchomiony na routerach nawiązuje połączenie pomiędzy sąsiednimi urządzeniami. W zależności od przypisania poszczególnych maszyn do określonych systemów autonomicznych może to być: | |valign="top"|Protokół BGP uruchomiony na routerach nawiązuje połączenie pomiędzy sąsiednimi urządzeniami. W zależności od przypisania poszczególnych maszyn do określonych systemów autonomicznych może to być: | ||
relacja wewnętrzna (Internal BGP) - gdy routery należą do tego samego systemu autonomicznego | relacja wewnętrzna (Internal BGP) - gdy routery należą do tego samego systemu autonomicznego | ||
Linia 364: | Linia 364: | ||
{| border="0" cellpadding="4" width="100%" | {| border="0" cellpadding="4" width="100%" | ||
|valign="top" width="500px"|[[Grafika:SK_M10_Slajd32.png]] | |valign="top" width="500px"|[[Grafika:SK_M10_Slajd32.png|thumb|500px]] | ||
|valign="top"|W module tym zostały przedstawione podstawowe informacje dotyczące znaczenia routingu w przesyłaniu danych w sieciach komputerowych. | |valign="top"|W module tym zostały przedstawione podstawowe informacje dotyczące znaczenia routingu w przesyłaniu danych w sieciach komputerowych. | ||
Wersja z 11:11, 21 wrz 2006
![]() |
Zadaniem protokołu routingu jest wybór optymalnej trasy dla przesyłanych pakietów. Pakiety mogą być wysłane krótszą trasą (przez mniejszą liczbę routerów) lub też trasą dłuższą. Optymalność obu tych tras może być wyznaczana na podstawie kilku cech, tak jak to zostało pokazane na rys. |
Wygląd pakietu dla protokołu RIPv2 został przedstawiony na rysunku. Poszczególne pola mają następujące znaczenie:
command - (1B) pole komendy version - (1B) Wersja protokołu RIP AFI (ang. address family identyfier) - (2B) pole identyfikujące jaki protokół będzie przesyłany. W przypadku IP wpisana jest tam wartość 2. Gdy pole ma ustawioną wartość 0xFFFF, to pakiet niesie informację o autoryzacji. route tag (2B) - określa czy trasa jest wysłana z lokalnego routera obsługującego protokół RIP (trasa wewnętrzna) czy też innego routera obsługującego inne protokoły (trasa zewnętrzna). IP address - (4B) jeśli w polu AFI jest wartość 2, to pole to przechowuje adres IP subnet mask - (4B) maska podsieci next hop - (4B) adres następnego routera na trasie (następnego skoku) metric - (4B) metryka Format pakietu zawierającego informację o autoryzacji zostanie pokazany na następnym slajdzie. |