Routing Information Protocol (RIP) –protokół bram wewnętrznych oparty na zestawie algorytmów wektorowych, służących do obliczania najlepszej trasy do celu.
Używany jest w systemach autonomicznych korzystających zprotokołu IP (zarówno wersji 4, jak i 6). Dzisiejszyotwarty standard protokołu RIP jest opisany w dokumentachRFC 1058 i STD 56. Obecnie najczęściej stosowana jest druga wersja protokołu RIP (RIPv2).
- Jest toprotokół trasowania działający na podstawiewektora odległości.
- Do utworzenia metryki stosuje się jedynie liczbę przeskoków (liczba kolejnych routerów na danej trasie).
- Jeżeli liczba przeskoków osiągnie 15, pakiety na następnym routerze zostaną odrzucone.
- Aktualizacjetrasowania są rozgłaszane tylko dorouterów sąsiednich.
- Ma niskie wymagania sprzętowe, przez co może być używany przez wszystkie routery.
- RIP wysyła informacje o trasach w stałych odstępach czasowych (domyślnie co 30 sekund) oraz po każdej zmianietopologii sieci.
- Pomimo wieku oraz istnienia bardziej zaawansowanych protokołów wymiany informacji o trasach RIP jest ciągle w użyciu. Jest dobrze opisany i łatwy w konfiguracji i obsłudze.
- Wadami protokołu RIP są wolny czas konwergencji (inaczej długi czas osiągania zbieżności), niemożliwość skalowania powyżej 15 skoków, a także potencjalny wybór nieoptymalnych ścieżek.
- Uaktualnienia protokołu RIP przenoszone są przezUDP naporcie 520 (w wersji drugiej wykorzystywana jest technologiamulticast na adres 224.0.0.9).
- RIP w wersji pierwszej jest protokołem trasowania klasowego (ang. classful), w wersji drugiej – bezklasowego (ang.classless).
- Standardowydystans administracyjny dla protokołu RIP wynosi 120.
Istnieją trzy wersje protokołu Routing Information Protocol, oznaczone odpowiednio RIPv1 (version 1), RIPv2 (version 2) oraz RIPng (next generation).
Oryginalna specyfikacja znajduje się w dokumencie RFC 1058. Okresowe aktualizacje dotyczące routingu nie przenoszą informacji o podsieci. Nie ma też cechVLSM. Z tych powodów wszystkie podsieci w danej klasie sieci muszą mieć ten sam rozmiar. RIPv1 zlicza jedynie do 15 przeskoków. Z tego powodu, gdy na trasie między dwoma routerami jest ich więcej, dany pakiet nie dotrze do adresu docelowego.
| + | Bity 0 - 7 | 8 - 15 | 16 - 31 |
|---|
| 0 | Polecenie | Numer wersji | Pole zerowe (1) |
|---|
| 32 | Identyfikator Rodziny Adresów (AFI) | Pole zerowe (2) |
|---|
| 64 | Adres sieciowy |
|---|
| 96 | Pole zerowe (3) |
|---|
| 128 | Pole zerowe (4) |
|---|
| 160 | Metryka |
|---|
- Polecenie
- Opisuje, czy pakiet jestżądaniem uaktualnienia, czyodpowiedzią na żądanie.
- Numer wersji
- Opisuje numer wersji protokołu (1 lub 2).
- Pole zerowe (1)
- Musi być wyzerowane w RIPv1. W RIPv2 jest to numer domeny routingu.
- Identyfikator rodziny adresów
- Opisuje rodzinę adresów, do której należy adres w polu adresu sieciowego. Dla rodziny adresów IP wartość AFI równa jest liczbie 2.
- Pole zerowe (2)
- W RIPv1 musi być wyzerowane, w RIPv2 jest toznacznik trasy (ang.route tag)
- Adres sieciowy
- Ponieważ protokołu RIP używa się w sieciachIP, to adres ten jestadresem IP. W zależności, czy pakiet ten jest żądaniem czy odpowiedzią (określone jest to w polu „Polecenie”), zawiera odpowiednio adres nadawcy lub adres z przesyłanej tabeli tras nadawcy.
- Pole zerowe (3)
- W RIPv1 musi być wyzerowane, w RIPv2 w tym miejscu ustawiona jestmaska podsieci adresu z pola wcześniejszego.
- Pole zerowe (4)
- W RIPv1 musi być wyzerowane, w RIPv2 w tym miejscu ustawiony jest adres IP następnego rutera pośredniczącego w przekazywaniu pakietów dla danej trasy (ang.Next Hop) – tylko, gdy pakiet jest odpowiedzią (przesyła wpisy ze swojejtablicy trasowania).
- Metryka
- Wartość metryki dla danej trasy. Reprezentuje odległość (w sensie logicznym, nie fizycznym) do celu, jest sumą kosztów poszczególnych łączy pośredniczących (najczęściej równa się ilości przeskoków, gdyż łącza pośredniczące mają domyślny koszt równy 1).
- G.G. Malkin G.G.,RIP Version 2, STD 56,RFC 2453,IETF, listopad 1998,DOI: 10.17487/RFC2453,ISSN2070-1721,OCLC 943595667 (ang.).
- C.L.C.L. Hedrick C.L.C.L.,Routing Information Protocol,RFC 1058,IETF, czerwiec 1988,DOI: 10.17487/RFC1058,ISSN2070-1721,OCLC 943595667 (ang.).
