Teraz Jesteś w Home Page > Akademia Cisco CCNA > Protokoły routingu z wykorzystaniem wektora odległości

1.Wstęp
2.Uaktualnienia protokołu Distance Vector
3.Problem pętli w protokołach typu Distance Vector
4.Maksymalna ilość skoków
5.Eliminowanie pętli za pomocą techniki Split Horizon
6.Unikanie pętli routingu za pomocą uaktualnień
7.Zapobieganie pętlą routingu za pomocą czasu Holddown
8.Routing RIP
9.Konfiguracja RIP
10.Użycie polecenia ip classless
11.Prosta konfiguracja RIP
12.Weryfikacja konfiguracji RIP
13.Problemy z uaktualnieniem RIP
14.Zapobieganie uaktualnieniom routingu
15.RIP i Load Balancing
16.Load Balancing i wielokanałowa ścieżka
17.RIP i routing statyczny
18.Cechy IGRP
19.Metryki IGRP
20.Routing IGRP
21.Cechy stabilności IGRP
22.Konfiguracja IGRP
23.Migracja z RIP do IGRP
24.Weryfikacja konfiguracji IGRP
25.Problemy z IGRP

Protokoły routingu z wykorzystaniem wektora odległości

Distance vector routing protocols

Wstęp

Dynamiczne protokoły routingu mogą znacznie ułatwić prace każdego administratora sieci. Konfiguracja routingu dynamicznego nie zajmuje tak wiele czasu jak konfiguracja routingu statycznego. Dynamiczne protokoły routingu pozwalają także reagować routerowi na zmiany w sieci, bez potrzeby angażowania w to administratora. Jednakże routing dynamiczny ma pewne wady i może sprawaiać pewne problemy.

Routing Information Protocol (RIP) jest protokołem typu distance vector działąjącym w tysiącach sieci na całym świecie. Fakt, że RIP jest standardem otwartym sprawia, że jest on bardzo prosty do implementacji i bardzo chętnie wybierany przez administratorów, mimo że nie posiada takich możliwości jak bardziej zaawansowane protokoły. Protokół RIP nadaje się także świetnie do nauki routingu. Podobnie jak RIP, także i Interior Gateway Routing Protocol (IGRP) jest protokołem typu distance vector. IGRP jest jednak bardziej kompleksowym protokołem i wykorzystuje większą liczbę parametrów w celu wybrania najlepszej scieżki dla pakietu.

Uaktualnienia protokołu Distance Vector

Uaktualnienia w tablicy routingu pojawiają się co pewien stały i określony czas, lub gdy w sieci zostaną wykryte jakieś zmiany. Uaktualnienia te są bardzo ważne i sprawiają, że protokół jest bardziej wydajniejszy. W procesie poznawania sieci routery wymieniaja sie między sobą zdobytymi informacjami wysyłąjąc własnie takie uaktualnienia. Algorytmy routingu typu distance vector domagają sie od routera, aby ten co pewien czas rozsytał do wszystkich swoich bezpośrednich sasiadów swoją aktualną tablicę routingu. Tablica routingu zawiera informacje na temat kosztu ścieżki, któy jest określony za pomocą metryk routingu oraz logiczny adres do pierwszego routera, któy znajduje sie na tej ścieżce.

Problem pętli w protokołach typu Distance Vector

Pętle routingu pojawiają się, gdy tablice toutingu są niezgodne z rzeczywistym stanem sieci, lub gdy zbieżność sieci (w przypadku jakiś zmian) jest osiągana zbyt długo.

Przed awarią sieci 1 wszystkie tablilce routingu były poprawne i sieć miała osiągniętą zbieżność. Router C preferuje scieżkę do sieci 1 poprzez router B, jego dystans do tej sieci w tym przypadku wyności 3. Kiedy sieć 1 nie jest osiągalna router E wysyła aktualizację do routera A, router A przestaje wysyłać pakiety do sieci 1, ale routery B, C i D dalej to jeszcze robią, ponieważ nie zostały poinformowane jeszcze o awarii. Kiedy router A roześle aktualizację tablicy routingu, routery B i D też przestaną wysyłać pakiety do sieci 1, jednak router C nie otrzymał jeszcze aktualizacji i dalej wysyła pakiety do sieci 1. Dla routera C sieć 1 jest cigle osiągalna poprzez router B. Kiedy router C wyśle swoją aktualizację z niezgodną tablicą routingu do routera D, wtedy dla routera D sieć 1 będzie osiągalna także przez router B. Następnie router D wyśle złe informacje do routera A. Router A następnie roześle fałszywe informacje do routera E i B. W takiej sytuacjie każdy pakiet przeznaczony do sieci 1 będzie krążyć od routera C do B następnie do routera A i z routera A do routera D skąd będzie wracał spowrotem do routera C.

Maksymalna ilość skoków

Wadliwe informacje na temat sieci 1 będą krążyć między routerami tak długo, aż coś przerwie ten proces. Taki stan nazywany jest liczeniem do nieskończoności. Gdyby routery pozwalały na nieskończoną ilość skoków, pozwoliłoby to na istnienie w sieci złośliwych pętli. Aby niedopóścić do nieskończonych pętli protokół routingu zlicza przez ile routeró przeszedł pakiet. Algorytmy protokołów routingu są wstanie same dokonać korekt podczas występowania pętli. Algorytm definiuje maksymalną liczbę skoków jaką może przebyć pakiet od źródła do celu. Protokół RIP akceptuje maksymalnie 15 skoków (jeden skok to jeden napotkany router), jeżeli pakiet przekroczy tą liczbę jest porzucany.

Eliminowanie pętli za pomocą techniki Split Horizon

Pętle routingu pojawiają się również, gdy uaktualnienie, które wraca do routera jest niezgodne z tym jakie ten router rozesłał. Oto przykład jak dochodzi do takiej sytuacji.
Router A wysyła uaktualnienie do routera B i D informując, że sieć 1 nie jest dostępna. Jednak router C w tym samym czasie wysyła uaktualnienie też do routera B, że sieć 1 jest dostępna w czterech skokach, drogą przez router D. Router B wnioskuje niewłaściwie, że Router C zna dobrą ścieżkę do sieci 1, mimo mniej korzystnej metryki. Router B wysyła uaktualnienie do Routera A o nowej ścieżce do sieci 1. Więc router A ustala, że pakiety przeznaczone do sieci 1 może wysłać bezpośrednio do routera B. Router B ustala zaś, że pakiety otrzymane od routera A i skierowane do sieci 1 może kierować dalej do routera C, ten zaś z kolei wysyła je do routera D. Każdy pakiet przeznaczony do sieci 1 będzie krążył między routerami. Technika Split Horizon stara się zapobiegać takiej sytuacji. Jeżeli router A wysyła uaktualnienia na temat sieci 1 do routera B, to router B nie wysyła z powrotem do routera A uaktualnień na temat tej sieci. Technika ta redukuje ilość niepoprawnych informacji oraz ilość nagłówków routingu jakie krążą w sieci.

Unikanie pętli routingu za pomocą uaktualnień

Każda nowa tablica routingu jest rozsyłana do wszystkich bezpośrednich sąsiadów w regularnych odstępach czasu. Na przykład protokół RIP rozsyła swoje uaktualnienia co 30 sekund. Uaktualnienia są rozsyłąne również natychmiast po wykryciu zmian w topologii sieci. Taka technika ma zapobiegać przekroceniu czasu holdtime po którym router lub sieć stają się nieosiągalne.

Zapobieganie pętlą routingu za pomocą czasu Holddown

Technika Holddown zabobiega liczeniu skoków do nieskończoności. Kiedy router otrzymuje wiadomość od sąsiada, któa wskazuje na to ,że wcześniej niedostępna sieć jest juz dostępna, zaczyna naliczać czas Holddown. Jeżeli do czasu wygaśnięcia czasu Holddown router otrzyma ponownie wiadomość od sąsiada, że ta sieć jest ciągle dostępna, to wtedy czas Holddown jest zerowany i naliczany od nowa. Czas Holddown jest zerowany także w przypadku otrzymnia wiadomości od innego sąsiada, jeżeli jego metryki są lepsze. W przypadku, gdy uaktualnienie pochodzi od routera o gorszych metrykach czas Holddown nie jest zerowany i jest naliczany nadal, a uaktualnienie jest ignorowane.

Routing RIP

Nowszy otwarty standard protokołu RIP jest czasami nazywany IP RIP, jego specyfika jest opisana w dwóch dokumentach. Pierwszy z nich to Request for Comments (RFC) 1058, a drugi to Internet Standard (STD) 56. RIP ewoulował przez lata wywodząc się z innego protokołu o nazwie Classful Routing Protocol. Pierwsza wersja tego protokołu rozwija się nadal przekształcając się w Classless Routing Protocol, czyli RIP v2. RIP w wersji drugiej obsługuje między innymi:

RIP zapobiega pętlą routingu stosując limit maksymalnej ilości skoków między źródłem i celem informacji. Maksymalna ilość skoków wynosi 15. RIP ma zaimplementowany mechanizm split horizon i holddown, w celu zapobiegania powstawaniu pętli.

Konfiguracja RIP

Polecenie router rip uaktywnia protokół. Jednak wcześniej mósimy wybrać interfejs, na którym RIP ma być uruchomiony. Należy także podać adres IP sieci oraz adres IP interfesju. Protokół RIP rozsyła swoje uaktualnienia w regularnych odstępach czasu. Kiedy router otrzyma uaktualnienie zawieraące zmiany w topologii sieci wpisuje je do stwojej tablicy routingu i w razie konieczności wybiera nowa trasę routingu dla pakietów. Przykładowa konfiguracja protokołu może wyglądać następująco:

BHM(config)#router rip -wybranie protokołu routingu
BHM(config-router)#network 10.0.0.0 -wybór sieci
BHM(config-router)#network 192.168.13.0 -Wybór sieci

Interfejsy routera, któe są podpięte do sieci 10.0.0.0 i 192.168.13.0 będą rozsyłać i odbierać uaktualnienia protokołu. To pomoże routerowi nauczyć się topologii sieci. Aby protokół działał poprawnie konieczne jest wybranie sieci i włączenie protokołu. Następujące elementy nie s a konieczne do poprawnego działania protokołu:

Użycie polecenia ip classless

Czasami router może otrzymać pakiet, któy jest przeznaczony do nieznajej mu części sieci (podsieci). Zadaniem IOS jest dostarczenie pakietu do najbardziej prawdopodobnego celu dla tego pakietu. Router rozsyła pakiet do tak zwanej supersieci. Na przykład przedsiębiorstwo używa następujących adresów IP 10.10.0.0/16, w takim przypadku supersieć będzie mieć adres 10.10.0.0/24. POlecenie ip classless jest włączone domyślnie w systemach IOS zaczynając od 11.3. Aby polecenie było nieaktywne należy wpisać przed nim no. Jeżeli ta cecha systemu IOS zostanie wyłączona, pakiet który jest przeznaczony do nieznanej części sieci zostanie anulowany przez router. Ip classless zwiększa tylko efektywność w przesyłaniu pakietów, i nie symuluje tablicy routingu. Najbardziej pogmatwane jest to, że router użyje routingu domyślnego tylko wtedy, gdy nie posiada wpisu w tablicy routingu. Router podsumowuje, że wszystkie podsieci należące do bezpośrednio podłączonej sieci powinny być wpisane w tablicy routingu. Jeżeli pakiet, który został odebrany należy do nieznanej podsieci , która powinna się znjadować w sieci głównej to router uzna, że ta podsieć nie istnieje. Więc pakiet zostanie porzucony nawet gdy ma ustawiony routing domyślny. Konfigurując ip classless rozwiązujemy ten problem.

Prosta konfiguracja RIP

Routery RIP muszą przede wszystkim polegać na informacjach zdobytych od bezpośrednio podłączonych sąsiadów. Ogólnie taka cecha nazywa się routingiem opartym na pogłoskach (Routing By Rumor). RIP używa algorytmu typu distance vector. Wszystkie algorytmy typu distance vector potrzebują długiego czasu, aby osiągnąć zbieżność. Zbieżność osiąga się, gdy wszystkie routery posiadają te same aktualne informacje na temat topologii sieci. Aby zredukować liczenie do nieskończoności i pętle routingu RIP używa następujących technik:

Niektóre z tych technik wymagają dodatkowej konfiguracji. Protokół RIP pozwala pakietowa na przebycie maksymalnie 15 skoków. Wszytkie sieci, które się nie mieszczą w tym zakresie są uznawane za nieosiągalne. Technika split horizon opiera się na teorii, że nie należy wysyłać z powtorem uaktualnień do routera, od którego się te uaktualnienia otrzymało. W niektórych specyficznych topologiach może być konieczne wyłączenie tej techniki. Robimy to za pomocą polecenia:

GAD(config-if)#no ip split-horizon

Czas holddown jest kolejnym mechanizmem, w którym możemy wprowadzić pewne zmiany. Czas holddown zapobiega liczeniu do nieskończoności, ale rónież pozwala na szybsze osiągnięcie zbieżności sieci. Domyślny czas holddown dla protokołu RIP wynosi 180 sekund. Czas holdown może zostać skrócony przez administratora, w celu osiągnięcia szybszej zbieżności, ale należy to robić ostrożnie. Idealne ustawienia dla tego czasu powinny być trochę dłuższe niż, maksymalny czas jaki jest potrzebny na otrzymanie uaktualnienia od najdalszego routera. Na przykład jeżeli uaktualnienia są wysyłąne co 30 sekund, najdłuższa pętla dla danej sieci wynosi na przykład 120 sekund, to czas holddown powinien być trochę dłuższy niż 120 sekund. Aby zmienić czas holddown używamy polecenia.

Router(config-router)#holddown liczba sekund

Aby zbieżność została szybciej osiągnieta możemy także zmienić czas wysyłania uaktualnień. Protokół RIP domyślnie wysyła uaktualnienia co 30 sekund. Aby nie zapychać dodatkowo przepustowości łącza czas ten można wydłużyć. W przypadku chęci osiagnięcia szybszej zbieżności czas ten można skrócić. Robimy to następująco:

GAD(config-router)#pdate-timer liczba sekund

Kolejną cechą protokołów routingu jest niechciane rozsyłanie uaktualnień na poszczególnych interfejsach. Aby kontrolować ustawienia interfejsu, który chce rozsyłać takie uaktualnienia, administrator sieci może przełączyć interfejs w stan pasywny, wtedy interfejs nie będzie rozsyłał pakietów na temat topologii sieci. Ponieważ RIP jest protokołem, który rozsyła pakiety w technice broadcast, administrator ma możliwość konfiguracji tego protokołu także w sieciach, które nie rozsyłąja pakietów w technice broadcas, na przykład Frame-Relay. W tego typu sieciach router sam nie dowie się o swoich sąsiadach i trzeba go o tym poinformować. Domyślnie system IOS przyjmuje pakiety RIP w wersji 1 i 2, ale rozsyła tylko w pakiety w wersji 1. Administrator sieci może skonfigurować router, tak aby odbierał i rozsyłał pakiety tylko w wersji 1, lub tylko w wersji 2.

Weryfikacja konfiguracji RIP

Jest kilka poleceń, dzięki którym możemy zweryfikować poprawność konfiguracji protokołu RIP. Dwa z najbardziej znanych poleceń to show ip route i show ip protocols. Polecenie show ip protocolspokazuje protokoły routingu, które zajmują się dostarczaniem danych. Dane, które otrzymamy za pomocą tego polecenia mogą posłużyć do weryfikacji protokołu. Informacje jakie zdobędziemy to między innymi:

Dzięki poleceniu show ip route dowiemy się, czy routery od których otrzymaliśmy uaktualnienia są wpisane do tablicy routingu. Routery, które rozsyłają uaktualnienia protokołu RIP są oznaczone literką "R". Należy pamiętać, że zbieżność sieci otrzymujemy dopiero po jakimś czasie, więc musimy dać czas routerom za zapoznanie się z siecią. Dodatkowe polecenia, dzięki którym sprawdzimy poprawność protokołu RIP to:

Problemy z uaktualnieniem RIP

Większość błędów w konfiguracji protokołu RIP wynika z niewłściwych komunikatów w sieci, odłączenia podsieci lub efektu split horizon. Aby dogłębnie sprawdzić, co robi protokół RIP w sieci używamy polecenia debug ip rip. Za pomocą tego polecenia na konsoli zostana wyświetlone wszystkie uaktualnienia RIP jakie router wysyła i otrzymuje. Inne polecenia, dzięki którym możemy rozwiązywać problemy z protokołem RIP to:

Zapobieganie uaktualnieniom routingu

Konfigurując interfejs w tryb pasywny, sprawiamy że router nie będzie wysyłać uaktualnień za pomoca tego interfejsu. Blokada wysyłania ualktualnień spowoduje, że routery nie będą poznawać topologii sieci w sposób dynamiczny. Tryb pasywny dla protokołów RIP i IGRP sprawia, że Router nie wysyła uaktualnień, ale w dalszym ciągu nasłuchuje i odbiera uaktualnienia od sąsiadów.

RIP i Load Balancing

Technika Load balancing pozwala routerowi wybrać więcej niż jedną ścieżkę do docelowego adresu IP. Ścieżki te są ustalone statycznie przez administratora lub są kalkulowane i wytyczane dynamicznie przez protokół routingu, taki jak RIP. RIP może maksymalnie wytyczyć sześć równoczesnych ścieżek dla pakietu, lecz domyślnie jest ustawiony na wytyczanie czterech ścieżek. Śieżki mogą być typowane na podstawie obciążenia, przepustowości i niezawodności, lecz protokół RIP jako swoją metrykę stosuje ilość skoków i na podstawie tej liczby wyznacza najlepszą trasę dla pakietów.

Load Balancing i wielokanałowa ścieżka

Load Balancing określa zdolość routera do przysyłania pakietu do docelowego adresu IP, za pomocą więcej niż jednej ścieżki. Trasy te są ustawiane statycznie lub dynamicznie przez takie protokoły jak: RIP, EIGRP, OSPF i IGRP. Kiedy router nauczy się wszystkich ścieżek do określonej części sieci, przesyła pakiet ścieżką o najmniejszym dystansie administracyjnym.

ProtokółDomyślny dystans admnistracyjny
Connected interface0
Static route1
Enhanced IGRP summary route5
External BGB20
Internal Enhanced IGRP90
IGRP100
OSPF110
IS-IS115
RIP120
EIGRP external route<170
Internel BGB200
Unknow255

Gdy router pozna kilka ścieżek do określonej sieci, umieszcza w swojej tablicy routingu tę, która ma najmniejeszy dystans administracyjny. Czasami zdarzyć się może, że router musi wybrać jedną ścieżkę spośród kilku ścieżek o tym samym dystansie administracyjnym. W takim przypadku router wybiera ścieżkę z namniejszym kosztem obliczonym za pomoca metryk protokołu routingu. Każdy protokół routingu kalkuluje koszt ścieżki na podstawie swoich metryk. Czasami może zajść potrzeba ręcznego ustawienia kosztu, tak aby był możliwy load balancing. Jeżeli router zna kilka ścieżek z tym samym kosztem i z tym samym dystansem administracyjnym jest możliwe przeprowadzenie transmisji typu load balancing. System Cisco IOS pozwala na zapamiętanie maksymalnie sześciu równorzędnych ścieżek. Niektóre protokoły routingu typu Interior Gateway Protocol (IGP) mają swoje własne limity ścieżek, na przykład protokół EIGRP używa maksymalnie czterech ścieżek. Domyślnie większość protokołów routingu instaluje maksymalnie cztery rónoważne scieżki. Routing statyczny instaluje zawsze maksymalnie sześć ścieżek. Wyjątkiem jest protokół BGB, który pozwala zawszy tylko na jedną scieżkę. Cisco IOS mazwala na instalację od jednej do sześciu ścieżek. Liczbę ścieżek zmieniamy nastęującym poleceniem:

Router(config-router)#maximum-paths [number]

Protokół IGRP akceptuje maksymalnie sześć ścieżek. W celu wybrania ścieżki protokół RIP liczy ilość skoków, zaś protokół IGRP jako metrykę stosuje przepustowość łącza. Na rysunku poniżej widać, że router E może przesłać pakiet danych do routera A trzema różnymi trasami:

Router E wybierze ścieżke E-C-A, ponieważ ma najmniejszy koszt.

RIP i routing statyczny

Routing statyczny jest zdefiniowany przez użytkownika i wyznacza on jakąś jedną specyficzną scieżkę między źródłem i przeznaczeniem. Routing statyczny jest bardzo ważny ponieważ nie wymaga on od routera poznawania topologii sieci. Jest on także użyteczny podczas wytyczania tak zwanej bramy ostatniej ucieczki (ang. gateway of last resor). Jeżeli pakiet jest przeznaczony do podsieci, która nie jest wyraźnie spracyzowana w tablicy routingu to pakiet ten jest przesyłany za pomocą routingu domyślnego. Router, na którym działa protokół RIP może odbierać routing domyślny od innego routera, na którym działa RIP, za pomocą uaktualnień. Routing statyczny możemy usunąć z routera za pomocą polecenia no ip route, które wydajemy w trybie globalnej konfiguracji. Administrator może tak skonfigurować routing dynamiczny, że będzie on ważniejszy od routingu statycznego. Taki efekt moża uzykać nadając odpowiednie dystansy administracyjne. Każdy protokół routingu dynamicznego ma swój domyślny dystans administracyjny. Przydzielamy, więc routingowi statycznemu większy dystans administracyjny, tak aby routing dynamiczny był ważniejszy i to on wytyczał możliwe ścieżki. Kiedy interfejs routera przejdzie to trybu down wszystkie wpisy dotyczące tego interfejsu są usuwane z tablicy routingu. Podobnie kiedy nie można znaleźć żadnego aktywnego następnego skoku, który jest określony w routingu statycznym, routing ten jest też usuwany z tablicy routingu.

Cechy IGRP

IGRP jest protokołem typu distanece vector (Interior Gateway Protocol). Protokoły routingu typu distance vector, wybierają ściezke dla pakietu mierząc odległość od źródła do celu. Routery używające tych protokołów muszą w określonych odstepach czasu wysyłać uaktualnienia dotyczące ich tablic routingu. Te pakiety informacyjne są przesyłane do każdego bezpośredniego sąsiada. IGRP jest protokołem rozwijanym przez Cisco. IGRP rozsyła swoje uaktualnienia co 90 sekund, pakiety te są rozsyłane do poszczególnych Systemów Autonomicznych. Cechy protokołów IGRP to:

Domyślnymi metrykami protokołu IGRP są przepustowość łącza i opóźnienie w dostarczaniu pakietów. Dodatkowo IGRP może być skonfigurowany, tak aby obsługiwał inne dodatkowe metryki.

Metryki IGRP

Polecemnie show ip protocols pokazuje różne parametry i informacje na temat sieci, które są podłączone do routera, na którym pracujemy. Wytyczaniem najlepszej ścieżki zajmują się odpowiednie algorytmy routingu, które wytyczają ściezkę na podstawie metryk protokołu. Najlepsza ścieżka to ta, która ma najmniejszą metrykę. IGRP kozysta z następujących metryk:

IGRP podczas wytyczania ścieżek korzysta ze złożonych metryck. Metryka jest wynikiem funkcji, w której pod uwagę bierze się takie wartości jak przepustowość, opóźnienie, obciążenie i niezawodność łącza. Domyślnie pod uwagę brane są tylko przepustowość łącza i opźnienie występujące na tym łączu. Reszta parametrów jest brana pod uwagę po wcześniejszej odpowiedniej konfiguracji. Polecenie show ip protocols pokazuje wartości metryk w nawiasach. Połaczenie z dużą przepustowością i małym opóźnieniem będzie posiadać niską, czyli dobrą metrykę.

Routing IGRP

Protokół IGRP obsługuje trzy typy routingu:

Routing wewnętrzny obejmuje transmisje między podsieciami, które są powiązane z jakimś interfejsem routera. Routing systemowy obejmuje przesyłanie danych w jednym Systemie Autonomicznym. Routing w jednym Systemie Autonomicznym może obejmować kilka oddalonych routerów i serwerów. Nie przesyłą on jednak informacji na temat podsieci. Routing zewnętrzny obsługuje przesyłanie pakietów poza System Autonomiczny. Aby wysłać informacje poza System Autonomiczny Cisco IOS odszukuje "bramę ostatniej ucieczki" (ang. gateway of last resort) i za jej pomoca przesyła dane poza AS. Jeżeli w Systemie Autonomiczny istnieje kilka takich bram, to każdy router może wybrać sobie inną trasę do przesyłania pakietów poza AS.

Cechy stabilności IGRP

Protokół IGRP zawiera w sobie kilka cech, które świadczą o jego stabilności i niezawodności:

Czasy Holddown służą do wykrycia niedziałających routerów. Kiedy router przestaje działać zmienia to topologię sieci. Dzięki czasom Holddown inne routery dowiadują się o tej awarii i zmianie w sieci. Split Horizon zapobiega wysyłaniu uaktualnienia do routera, od którego przyszło to uaktualnienie. Technika ta zapobiega powstawaniu pętli routingu. Technika Poison reverse updates zapobiega powstawaniu pętli routingu między sąsiadującymi routerami. Protokół IGRP rozsyła także co pewien czas inne dodatkowe informacje. Są to między innymi czasy: update, invalid, holddown i flush. Czas update określa co ile sekund ma być wysyłany pakiet z uaktualnieniem tablicy routingu. IGRP domyślnie wysyła takie pakiety co 90 sekund. Czas invalid określa jak długo router ma czakać na uaktualnienie (które z jakiś powodów się nie pojawiło) zanim określi błąd routingu. Domyślnie jest to trzykrotny czas update, czyli domyślnie jest to 270 sekund. Czas Holddown określa sumę czasów, po których pakiet jest ignorowany, jeżeli w tym czasie nie dotarł do celu. IGRP domyślnie stosuje trzykrotność czasu update plus 10 sekund, czyli pakiet musi osiągnąć cel w ciągu 280 sekund zanim zostanie zignorowany. Wreszcie czas flush określa ile czasu musi upłynąć zanim wpis w tablicy routingu zostanie usunięty. Protokół IGRP domyślnie stosuje siedmiokrotność czasu update , czyli 630 sekund. IGRP nie obsługuje podsieci o zmiennej masce ( variable length subnet masks -VLSM). Problem ten zostanie raczej rozwiązany w drugiej wersji tego protokołu.

Konfiguracja IGRP

Aby skonfigurować protokół IGRP korzystamy z polecenia router igrp. Aby dezaktywować protokół korzystamy z polecenia no router igrp.

RouterA(config)#router igrp as-number
RouterA(config)#no router igrp as-number
RouterA(config)#network 172.16.0.0

Migracja z RIP do IGRP

Projektując protokół IGRP we wczesnych latach osiemdziesiątych firma Cisco jako pierwsza staneła przed problemem powiązania ze sobą datagramów dwóch różnych (wewnętrznych) protokołów routingu. Protokół IGRP wyznacza najlepszą ścieżkę na podstawie przepustowości i opóźnienia na łączu między dwoma routerami. IGRP osiąga także szybiej zbieżność sieci i nie ma ograniczonej liczby skoków, tak jak RIP. Kroki przejścia z protokołu RIP do IGRP są następujące:

Weryfikacja konfiguracji IGRP

Aby sprawdzić, cz protokół IGRP został prawidłowo skonfigurowany wydajemy polecenie sho ip route i szukamy routerów oznaczonych literką I, oznacza to że na nich działa protokół IGRP. W celu dalszej weryfikacji możemy użyć następującej poleceń:

Problemy z IGRP

Większość problemów z protokołem IGRP wynika z błędnie wprowadzonych adresów IP sieci lub podsieci lub z niewłaściwego numeru Systemu Autonomicznego. Następujące polecenia mogą pomóc w rozwiązaniu pojawiających sie problemów:

Powrót na poczętek