Protokół RIP i RIPv2

background image

Protokół RIP i RIPv2

background image

RIPv1

• jest to protokół typu DistanceVector
• jest to protokół klasowy (ang. classful), co oznacza, że informacjom o podsieciach

nie towarzyszą informacje o maskach tych podsieci oraz że RIP dokonuje
sumaryzacji na granicy sieci

• RIP pracuje w oparciu o protokół UDP, zarówno port źródłowy, jaki docelowy ma

numer 520

• do rozsyłania informacji RIP używa adresu docelowego IP typu

localbroadcast (255.255.255.255)

• domyślnie informacje o podsieciach rozsyłane są co 30 sekund

(periodicupdates)

• implementacja Cisco używa mechanizmu holddown, przy czym

holddowntimer= 180 sekund

• używa mechanizmów splithorizon oraz poisonreverse
• stosuje triggeredupdates
• w jednym pakiecie RIP może przesłać informację o 20 podsieciach.

background image

Protokół RIP - parametry

czasowe

• Update (czas aktualizacji) - czas wysyłania kolejnych aktualizacji. W protokole RIP domyślnie

około 30 sekund.

• Invalid (trasa nieważna) - zegar uruchamiany razem z ostatnią aktualizacją. Przy braku

aktualizacji, po przekroczeniu tego czasu trasa oznaczana jest jako nieważna, ale nie jest
automatycznie usuwana z tabeli routingu, tylko przechodzi w tryb przytrzymania trasy (hold
down). W protokole RIP czas ten wynosi domyślnie 180 sekund (6 czasów aktualizacji).

• Hold down (przytrzymywanie trasy) - czas przetrzymywania w tabeli routingu tras

nieważnych (nieaktualizowanych). Trasa w tym trybie oznaczana jest w tabeli routingu jako
"possibly down", ale jest cały czas wykorzystywana do wysyłania pakietów i router nie
akceptuje ewentualnych ogłoszeń tej trasy od innych sąsiadów. Zastosowano tutaj zasadę, że
lepiej przytrzymać w tabeli routingu trasę być może uszkodzoną, niż zbyt szybko przełączyć
się na inną trasę do tej samej sieci, ale z wyższą metryką. W protokole RIP czas ten wynosi
domyślnie 180 sekund (chyba że wcześniej skończy się czas flush).

• Flush (usuwanie trasy z tabeli) - czas, po którym trasa nieaktualizowana usuwana jest z tabeli

routingu. Zegar ten uruchamiany jest razem z ostatnią aktualizacją trasy. Ponieważ w
protokole RIP czas ten wynosi domyślnie 240 sekund, więc w praktyce trasa nieaktualizowana
usunięta zostanie z tabeli routingu już po 60 sekundach trybu hold down (plus 180 sekund
czasu invalid).

background image

RIPv1

Command= 1

or 2

VersionVersion =1

Must be zero

Address family identifiet (2= IP)

Must be zero

IP Address (Network Address)

Must be zero
Must be zero

Metric (Hops)

Multiple Route Entris, up to a maximum of 25

0 7|8 15|16 23|24

31

background image

RIPv2

Protokół RIPv2 jest rozszerzeniem protokołu RIP. W ramach rozszerzonej funkcjonalności udało
się wyeliminować większość ograniczeń protokołu RIP-1:
• RIPv2 jest protokołem bezklasowym (ang. classless), co oznacza, że wraz z informacjami o

podsieciach, przenoszona jest także informacja o maskach podsieci.

• RIPv2 nie używa adresu localbroadcast(255.255.255.255) do rozgłaszania swoich informacji –

zamiast tego zastosowano adres multicast 224.0.0.9

• RIPv2, jako protokół bezklasowy, wspiera nieciągłe podsieci oraz adresację VLSM
• RIPv2 obsługuje autentykację informacji, co oznacza, że każdy z routerów może zostać

wyposażony w hasło, które służy do weryfikacji autentyczności nadsyłanych informacji o
podsieciach

Bez zmian pozostały następujące cechy protokołu RIP-1:
• RIPv2 używa protokołu transportowego UDP i portu 520
• metryka to hop count, wartość metryki: 1 – 16
• RIPv2 domyślnie dokonuje automatycznej sumaryzacji na granicy sieci głównych
• RIPv2 obsługuje do 16 równoległych tras o tej samej wartości metryki
• RIPv2 pozostaje protokołem DistanceVector
• liczniki czasu w RIPv2 są takie same jak w RIP-1

background image

RIP w wersji pierwszej ma wiele wad, przede wszystkim jest protokołem pełno klasowym, nie przesyła
informacji o maskach, w związku z tym sumaryzuje tam, gdzie nie chcemy, nie obsługuje nieciągłych
podsieci, nie obsługuje podsieci o zmiennej długości maski. Dostrzeżono te wady i rozszerzono protokół RIP
o wersję drugą, który to
jest protokołem bezklasowym, co oznacza, że przesyła informacje o maskach podsieci, a więc wszystkie

niedogodności RIP-a w wersji pierwszej odpadają.

Nie używa też adresu rozgłoszeniowego, ale dedykowanego adresu multikastowego 224.00.9. To jest adres

klasy D. Adresy multikastowe są to adresy klasy D. Ten adres jest zarezerwowany i tylko RIP ma prawo nim
się posługiwać.

Jako protokół bezklasowy wspiera zarówno nieciągłe podsieci, jak i adresację o zmiennej długości maski,

więc jest lepiej.

Mało tego, obsługuje też autentykację, więc możemy zapewnić, że weryfikujemy, czy informacje

otrzymujemy od uprawnionych routerów czy od jakichś przypadkowych. I tę od przypadkowych ignorować.

Bez zmian pozostały takie cechy,
jak password czy UDP i port 520.
Metryka też pozostała bez zmian, jest to wciąż hop count, od 1 do 15 są to wartości użyteczne, 16 jest

wartością oznaczającą nieskończoność.

Nie zmienił się tez administrative distance. Mimo że można to wyłączyć to domyślnie RIP w wersji drugiej

dokonuje automatycznej sumaryzacji na granicy dwóch sieci głównych.

Podobnie jak RIP pierwszy obsługuje do 16-tu ścieżek o tej samej wartości metryki,
pozostaje wciąć protokołem distance vector
i posługuje się dokładnie tymi samymi licznikami czasu.

background image

Różnice pomiędzy protokołem

RIP a RIPv2

RIP v1

• Obsługuje tylko protokoły klasowe routingu
• Wysłane aktualizacje tras nie zawierają informacji o sieciach
• Wszystkie urządzenia w podsieci muszą używać tej samej maski podsieci

(nie obsługuje routingu z Uwzględnieniem prefiksu)

• Wysyłane aktualizacje nie mogą być uwierzytelniane
• Rozgłasza na adresie 255.255.255.255.

RIPv2

• Obsługuje protokoły bezklasowe routingu.
• Wysłane aktualizacje tras zawierają informacje o maskach podsieci.
• Po zastosowaniu techniki VLSM obsługuje routing z uwzględnieniem prefiksu,

dzięki czemu różne podsieci tej samej sieci mogą mieć różne maski podsieci.

• Wysyłane aktualizacje mogą być uwierzytelniane
• Aktualizacje tras są rozsyłane grupowo za pośrednictwem
• adresu klasy D 224.0.0.9, co zwiększa wydajność rozsyłania

background image

RIPv2

Command= 1

or 2

VersionVersion =2

Must be zero

Address family identifiet (2= IP)

Route Tag

IP Address (Network Address)

Subnet Mask

Next Hop

Metric (Hops)

Multiple Route Entris, up to a maximum of 25

0 7|8 15|16 23|24

31


Document Outline


Wyszukiwarka

Podobne podstrony:
Protokół RIP
7 Protokół RIPv2
PROTOKOŁY DYNAMICZNEGO ROUTINGU IP – RIP i OSPF
Wykład12 Sieć z protokołem X 25 i Frame Relay
Wykład10a Sieć z protokołem X 25 i Frame Relay
05 LAN Protokol IPid 5733 ppt
Protokół o zapobieganiu, zwalczaniu oraz karaniu handlu ludźmi
protokol2
PROTOKOL DYPLOMATYCZNY manulas MBak
II seria, Protokól 11ME wersjab
3 Wzm operacyjny protokol zima
ćw 10 tabelki do protokołu
Protokół sekcji zagadnienia
II seria, Protokól 2ME b
034 ROZ M I w sprawie wzoru protokołu obowiązkowej kontroli
protokol nr2
Asertywnosc I Sztuka Celnej Rip Nieznany
Protokoly 291004
chromatografia jonowymienna 2, Rok I, chemia fizyczna, chemia fizyczna-protokoły

więcej podobnych podstron