четвъртък, 29 януари 2015 г.

Вътрешни портални протоколи IGP. Протокол RIP-описание. Протокол за рутиране OSPF

Вътрешни портални протоколи (Interior Gateway Protocols - IGP) - интегрирани са в повечето операционни системи и рутери.

Протокол RIP (Routing Information Protocol) - стандартизиран от IAB протокол. Статусът му е избираем, т.е. може да се използва или не в дадена система. Когато е избран, използването му трябва да става в съответствие с RFC 1058.

RIP е базиран на два протокола за рутиране - Xerox PUP и XNS. RFC за протокола е издаден след появата на няколко негови варианта. RIP е протокол за векторно рутиране, подходящ за малки мрежи. Налични са две версии - RIP-1 и RIP-2.

RIP-1 е широко използван протокол с няколко съществени ограничения. RIP пакетите се предават по мрежата в UDP дейтаграми (User Datagram Protocol), които на свой ред се носят в IP дейтаграми. RIP-1 имат максимален размер 512 октета. По-големите таблици трябва да се изпращат с няколко дейтаграми. RIP дейтаграмите се изпращат в локална мрежа посредством множествен адрес на ниво MAC и IP мрежов или подмрежов адрес.

В общия случай рутерите използват RIP протокола в активен режим - изпращат своите векторни таблици и ги обновяват въз основа на получените таблици от съседите. Крайните възли, ползващи RIP, работят в пасивен режим - само обновяват своите таблици въз основа на получените от съседите, но не ги изпращат. RIP определя два типа пакети: заявка и отговор (request and response)

Пакет-заявка се изпраща от рутерите за да поискат от съседите част от тяхната векторна таблица (ако пакетът съдържа целеви компютри или мрежи) или цялата таблица (ако пакетът не съдържа такива).

Пакет-отговор се изпраща от рутер за предаване на своята векторна таблица при следните условия:
  • на всеки 30 секунди
  • в отговор на пакет-заявка
  • при промяна на векторната таблица (в случай, че се поддържа принудително обновяване на таблиците) 

Като мерна единица се използва броя на преходите. Този подход е  разумен, но не осигурява предпочитание за маршрути през бързи мрежови връзки (през някои локални мрежи) вместо доста по-бавните глобални мрежи. Съобщенията за обмен на таблиците се изпращат до всички интерфейси, поддържащи RIP. Максималният брой мрежи, описани в едно съобщение е 25 и това е един от съществените недостатъци на този протокол.

Активните и пасивните системи прослушват всички пакети-отговори и обновяват своите таблици. Маршрут до даден целеви адрес, отказан от векторната таблица на съседа, се пази до намирането на алтернативен най-кратък път или за времето на предаване на следващите 6 последователни пакета-отговори ако в тях не се срещне отново. В останалите случаи маршрутът се изтрива.

Когато RIP се използва с IP, фамилията адресни идентификатори е 2 и адресното поле е 4 октета. За намаляване на проблема с броенето до безкрайност, максималната оценка на маршрута е 16 (недостъпен адрес). Форматът на RIP пакета е даден на фиг.5,21



RIP не предава подмрежови маски. Рутер, получаващ RIP пакет-отговор, трябва да има предварително информацията за мрежовите подмаски, за да идентифицира правилно мрежата и конкретния компютър.

Невъзможно е използването на RIP в сложна мрежа с променлива дължина на мрежовата подмаска, понеже ако се знае специфичната подмаска на дадена IP мрежа, RIP протоколът ще интерпретира цялата останала информация за рутиране към тази мрежа на базата на тази единствена маска. Ако се получи пакет със значещи битове в полето за адрес на конкретен компютър, той ще бъде интерпретиран като единичен маршрут до компютър с маска 255,255,255,255.

Въпреки, че протоколът RIP е лесно приложим, неговата реализация има няколко съществени недостатъка:

  • мрежовите подмаски не се обновяват;
  • няма механизъм за разпознаване - това позволява включване в мрежата на рутер, използващ RIP, което е предпоставка за повреди в маршрутните таблици;
  • използват се пълни множествени обяви (broadcast), което е неефективен подход за разпространяване на маршрутна информация.

Протокол за рутиране RIP-2 - той е стандартен протокол с изборен статус. Описан е в RFC 1723. Прилага се за преодоляване на голяма част от недостатъците на предходната версия.





Няма коментари:

Публикуване на коментар

Equations

π 8 3